The Wireless Communication Library works with different hardware devices: Bluetooth, IrDA, serial, and WiFi. These devices send notifications (when the device is found, connected, disconnected, etc.) to an application through callbacks in different system-defined threads. However, UI frameworks (VCL, MFC, WinForms, WPF) require that UI updates always be performed in the main UI thread. To be able to work with the UI frameworks, the Wireless Communication Library needs to synchronize those callbacks with an application's main thread. To achieve this, the Wireless Communication Library uses an internal inter-threading communication mechanism called Messaging.

The Messaging Subsystem

The Wireless Communication Library messaging subsystem provides a universal and cross-platform easy way for inter-threading notifications. This subsystem allows sending notifications from one application's thread to another. The Wireless Communication Library uses this subsystem to deliver system notifications from system callbacks to the Wireless Communication Library objects. The messaging subsystem notifications are called messages. Sending messages is called synchronization. Currently, the Wireless Communication Library messaging works on Windows and MacOS (VCL edition with Lazarus).

The Wireless Communication Library provides two synchronization methods called message processing methods: synchronous and asynchronous. Each Wireless Communication Library component can use its own independent synchronization method. You can specify the message processing method by setting the MessageProcessing property. By default, synchronous message processing is used.

The message processing methods are described by the wclMessageProcessingMethod enumeration. The enumeration defines two values: the mpAsync is defined for asynchronous message processing, and the mpSync is defined for synchronous message processing.

ASYNCHRONOUS MESSAGE PROCESSING

The asynchronous message processing uses a separate thread for notifications delivery. It means that all the Wireless Communication Library> components' events will be called in a separate independent thread. This message processing method is useful for console or service applications. It can also be used in UI applications when you need to run some Wireless Communication Library functions in a separate thread. To switch a Wireless Communication Library component to the asynchronous message processing set the MessageProcessing property to mpAsync.

SYNCHRONOUS MESSAGE PROCESSING

The synchronous message processing uses Windows messages (on Windows platforms) for delivering notifications. It means that all the Wireless Communication Library components' events will be called in the same UI thread. To be able to receive the synchronous notifications (events), an application must have a UI and run a messages loop. It is possible to use synchronous message processing in non-UI threads, but such threads must have a message loop. This is the default Wireless Communication Library messages processing method.

MESSAGE PROCESSING IN BLUETOOTH FRAMEWORK

The Bluetooth Framework manages message processing methods in a little bit different way. You can change the message processing method of the wclBluetoothManager and the wclBleSniffer components only. All other Bluetooth Framework components select a message processing method automatically. If a component is created and used in the same thread that was used to open the wclBluetoothManager then the component will use the Bluetooth manager's message processing method. If a component is created and used in a separate thread (other than a thread used to open the Bluetooth manager), then it will use the asynchronous message processing method.

NOTE: Even if the audio components are shipped with the Bluetooth Framework, formally those components are part of the Audio Framework and use common synchronization settings as described above.