From Bright Pattern Documentation
< 3.11:Simplified-desktop-net-api-specification
Revision as of 20:12, 11 May 2016 by Sasha (talk | contribs) (Created new topic from branched topic Documentation:ServicePattern:simplified-desktop-net-api-specification:EventDelivery:3.10)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
• 3.10 • 3.11 • 3.12 • 3.13 • 3.14 • 3.15 • 3.16 • 3.17 • 3.18

Event Delivery

Communications with the softphone plugin are handled by the lowest level of the API; all transport is handled by the .NET platform and all transport-related events are delivered on threads maintained by the platform. Note that direct updating of the UI (either Windows Forms, or WPF) is only permitted on the UI thread - in most cases, the main thread of the application. Although different mechanisms exist to convey execution flow from non-UI to UI threads, the API has its own mechanism that allows receiving events emitted by the API classes on the UI thread - event dispatcher classes.

Each API class has a child class named eventDispatcher (referred to as "event dispatcher"). The event dispatcher class intercepts and re-emits all events emitted by its parent class, while guaranteeing that the events will be delivered on the thread on which the API has been created. Event handlers registered with the API’s event dispatcher class created on the UI thread may directly update elements of the application's UI.

All events emitted by all objects follow the Microsoft's guideline that asks that all event handlers take two parameters - the object that has emitted the event and another object that encapsulates all arguments of the event. Such an arguments object should inherit the System.EventArgs class and provide any additional data or capabilities in the form of additional properties and methods. All events emitted by the event dispatcher objects carry the reference to the original sender object.

< Previous | Next >