Intercepting Messages in Win32
Obtaining, decoding, and using messages in Windows programming.
Dec 15, 2006
Introduction
The Windows operating system is message based; nothing happens in the system unless a message is sent to an application telling it that something in the system has changed. Examples of events generating messages include:
- Mouse movement
- Keyboard
- Menu / button selection
- Window movement
The way that Windows handles messages is well documented. In fact, most of the messages are handled by the system itself. For example, a mouse movement to a menu item, selection of the top level menu, and subsequent conformation of the selection of a pull-down item is all handled by Windows. The application just receives a WM_COMMAND message indicating that an option has been chosen.
Windows provides handlers for most messages. An application window can be resized, moved, and many user interface items interacted with without ever bothering the parent application window. It is only when the programmer chooses to process a message class that things change.
Intercepting Application Messages
There is a difference between processing messages, and just intercepting them. Be very aware from the outset that any message intercepted, taken off an application queue, and not processed, is lost. That said, the Windows API provides a function, PeekMessage, designed solely with interception in mind.
Firstly, however, we should look at the standard message processing functions provided by Microsoft, using the GetMessage function. The message loop in the WinMain function of any Windows application usually looks something like:
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
The above will loop until there are no messages left to process. Each time a message arrives, it is Translated to remove virtual key-codes, and Dispatched to the Window Procedure (callback function) of the application. This is the standard processing - the thread will yield to Windows where appropriate (in the GetMessage call), and if we put some time consuming code in the while loop, we may notice a lag in processing.
However, GetMessage removes the message from the queue. To look at the queue without removing a message we use the PeekMessage function:
LPMSG msg, // The message
HWND hWnd, // The target window handle
UINT wFilterMin, // The start message
UINT wFilterMax, // The end message
UINT wRemove // PM_REMOVE or PM_NOREMOVE
);
Strictly speaking, we can still remove messages by using the PM_REMOVE flag value in the wRemove function parameter. The two Filter values can be used to limit the messages returned by PeekMessage. If 0 is specified in both, all messages are returned, one per call.
Intercepting Keyboard and Mouse Messages
By way of an example, let us consider the following call:
NULL, 0, 0, PM_NOREMOVE);
This would enable us to look at any message in any window associated with the calling application. We cannot, however, examine the message queues of other applications. Two important tasks that we can do are:
NULL, WM_MOUSEFIRST, WM_MOUSELAST, PM_NOREMOVE);
This will filter mouse messages, while:
NULL, WM_KEYFIRST, WM_KEYLAST, PM_NOREMOVE);
Will filter keyboard messages. These intercepts are useful in building applications that react in specific ways to the keyboard/mouse, but without actually removing any of the messages from their queues.
