Receiving and Dispatching Messages

To receive messages, call the GetMessage function. When a thread calls GetMessage, Windows CE examines the thread message queue for incoming messages. Windows CE processes messages in the following order:

1. Windows CE checks for messages placed on the queue by the SendMessage function. After the system removes the message from the queue, it dispatches the message to the appropriate window procedure from within the GetMessage function. This guarantees that the sender and receiver message queues remain synchronized. The receiver must call GetMessage for the sent messages to be processed.
2. If no sent message is found, Windows CE checks for messages placed on the queue by a call to PostMessage.
3. If no posted message is found, Windows CE checks the queue for messages posted by the user input system.

   By processing user input messages at a lower priority, the system guarantees that each input message and any posted messages that result from it are processed completely before moving on to the next input message.

4. If no posted input messages are found, Windows CE checks the queue for WM_QUIT messages placed on the queue by a call to the PostQuitMessage function.
5. If no posted quit messages are found, Windows CE checks the queue for WM_PAINT messages placed on the queue by the windowing system.
6. If no paint messages are found, Windows CE checks the queue for WM_TIMER messages placed on the queue by the timer system.

When GetMessage receives any of the previous messages, it returns the message content. The thread must call the DispatchMessage function to dispatch the message to the correct window procedure. If the message is a WM_QUIT message, the return value of GetMessage is zero, which causes the thread to end its message loop.

The system dispatches messages in the GetMessage call of the message loop, and the application dispatches messages by calling the DispatchMessage function in the message loop.

You might need to process messages you receive from GetMessage before you send them out using DispatchMessage. The most common processing routines are the TranslateMessage function, TranslateAccelerator, and IsDialogMessage. Some of these routines can dispatch messages internally because the application no longer needs to call DispatchMessage in the main message loop.

You usually call TranslateMessage before DispatchMessage. TranslateMessage determines which characters go with keyboard messages. TranslateMessage posts the characters to the message queue to be picked up on the next pass of the message loop.

To intercept keyboard messages and generate menu commands, call the TranslateAccelerator function. Call the IsDialogMessage function to ensure the proper operation of modeless dialog boxes.

You can remove a message from its queue with the GetMessage function. Call the PeekMessage function to examine a message without removing it from its queue. This function fills an MSG structure with information about the message. Use the PeekMessage function carefully because it does not block the waiting for a message event, which enables an application to continue processing regardless of messages in the queue. In a Windows CE–based application, if an application does not block the waiting for a message or some other event, the kernel cannot shift the CPU into low-power mode; this can quickly drain the device batteries.

When processing messages, Windows CE supports both system-defined messages and application-defined messages. System-defined messages have message identifiers ranging from 0 through 0x3ff. Messages with message identifiers ranging from 0x400 through 0x7fff are available for application-defined messages.

There are two types of system-defined messages: general window messages, which are used for all windows, and special purpose messages, which apply to a particular class of windows. General window messages cover a wide range of information and requests, including messages for input device and keyboard input, as well as window creation and management.

The prefix of the symbolic constant for the message generally identifies the category to which the message belongs. For example, general window messages all start with WM, whereas messages that apply only to button controls start with BM.

The following table shows Windows CE message types.

You can define messages for use by your own application's window. If you create messages, be sure that the window procedure that receives them interprets and processes them correctly. The operating system (OS) does not interpret application-defined messages.

In some situations, you need to use messages to communicate with windows that are controlled by other processes. In this situation, call the RegisterWindowMessage function to register a message identifier. The message number returned is guaranteed to be unique throughout the system. By using this function, you prevent the conflicts that can arise if different applications use the same message identifier for different purposes.

Windows CE does not support hooking messages because the extra processing required by hooks can impair the performance of Windows CE–based devices.

When handling messages in your application, be aware of the WM_HIBERNATE message. Windows CE defines a WM_HIBERNATE message to notify an application when system resources run low. When an application receives this message, it should attempt to release as many resources as possible. The system checks memory status at five-second intervals. Every Windows CE–based application that uses even moderate amounts of system resources should implement a handler for the WM_HIBERNATE message. If an application window is not visible, it cannot receive a WM_HIBERNATE message. This is because the WM_HIBERNATE message is sent only to applications that have a button on the taskbar, which only visible windows do. A hidden window will not get this message, even if it is a top-level, overlapped window.