Event-Driven Interface
As described in the corresponding section of the User Manual, the event driven interface can save your computational and USB resources and increase the application responsibility.
Each module has its own set of available events. The examples of how to handle and configure these events are provided in the corresponding parts of the current manual.
In the following sections we examine the general approach of DLN event processing and review two examples. The first example handles device connection/disconnection events and prints the corresponding messages at the standard output (stdout). The second example can be used as a generic events monitor. In addition to handling device connection/disconnection, it also processes all other event types. It dumps the event data at the standard output (stdout).
Events Queue
Notifications
The DLN library may notify the user application when new messages arrive from the device.
There are 4 different types of notifications:
Callback function.
Event object.
Window message.
Thread message.
You can configure the same notification settings for all the messages. To do so, call the DlnRegisterNotification() function and specify HDLN_ALL_DEVICES(0) value as a handle. In this case the DLN library will notify the user application about messages from all devices.
The DLN library may notify the application about messages from a specific device. To configure such notification settings, call the DlnRegisterNotification() function and specify the handle of the device. Streams (like devices) have their own handles. So, you may configure the notification settings for a specific stream as well.
You can use the DlnRegisterNotification() function several times, specifying various notification settings for different devices (streams). For example, if you have 4 devices, you may register certain notification settings for one device and different settings for other devices. When a device sends a message, the library checks the notification settings for current device. If the library finds such settings, the notification is generated. If there are no settings for current device, the library checks the notification settings for all devices. If there are no such settings either, the notification isn't generated and the message isn't pushed into the queue.
Sometimes it is useful when messages aren't pushed into the queue. It is most convenient for those who use only synchronous communication. During the synchronous communication the application doesn't call the DlnGetMessage() function. Thus the messages aren't removed from the queue. It leads to memory leak and eventually to memory overflow. If you don't want messages to be enqueued, you shouldn't register any notification settings.
If you want the messages to be enqueued without notification, do the following. Call the DlnRegisterNotification() function and specify DLN_NOTIFICATION_TYPE_NO_NOTIFICATION value as the notification type. In this case the messages will be pushed into the queue without notification to the user application. The messages can be obtained with the help of the DlnGetMessage() function.
To unregister the notification settings call the DlnUnregisterNotification() function.