Message Types

Messages come in many flavors, representing events at many different levels. Again, the Spy++ tool can help you appreciate the complex message set every single window must process. Use the Spy++ tool to select some simple element, such as a dialog box, to snoop on; then watch the seemingly endless cascade of messages streaming by in the Spy++ window as you move the mouse over a button in the dialog and click it. Table 7.1 shows the list of messages that appear as I dismiss the Word for Windows "About" dialog by clicking on its OK button.

Table 7.1: Messages sent to the Word for Windows "About" dialog when the user clicks the OK button.

Symbolic Identifier	Description
WM_LBUTTONDOWN	The left mouse button was pressed.
WM_PAINT	The OK button is repainted as it is pressed.
WM_LBUTTONUP	The left mouse button was released.
WM_PAINT	The OK button is repainted as it is released.
WM_WINDOWPOSCHANGING	The position of the window is about to change.
WM_WINDOWPOSCHANGED	The position of the window has just changed.
WM_NCACTIVATE	The window's title area has been activated.
WM_ACTIVATE	The window's client area has been activated.
WM_WINDOWPOSCHANGING	The position of the window is about to change.
WM_KILLFOCUS	The window is about to lose focus.
WM_DESTROY	The window is being destroyed.
WM_NCDESTROY	The title area of the window is being destroyed.

As you can see, messages representing every single occurrence, every single action are sent to the window for processing. Fortunately, an application does not have to be aware of the meaning of every single message. Instead of processing all possible messages, an application is free to "pick and choose"; messages that remain unprocessed are passed to the operating system's default message handler function.

Windows messages consist of several parts. Perhaps it is best to review the MSG structure, shown in Listing 7.1, which is used to represent messages.

Listing 7.1. The MSG structure.

typedef struct tagMSG {

HWND hwnd;

UINT message;

WPARAM wParam;

LPARAM lParam;

DWORD time;

POINT pt;

} MSG;

The first element of this structure, hwnd, uniquely identifies the window to which this message has been posted. Every window in Windows has such an identifier.

The next element identifies the message itself. This element may have hundreds of different values, indicating one of the many hundreds (literally!) of different messages that Windows applications may receive. Messages can be organized into several groups depending on their function. Message identifiers are usually referred to symbolically (such as, WM_PAINT, WM_TIMER) rather than by numeric value; these symbolic values are defined in the standard Windows header files. (You need only include windows.h; it, in turn, contains #include directives for the rest.)

By far the most populous group of Windows messages is the group of window management messages. The symbolic identifiers for these messages all begin with WM_. This group is so large, it only makes sense to further subdivide it into categories. These categories include DDE (Dynamic Data Exchange) messages, clipboard messages, mouse messages, keyboard messages, nonclient area messages (messages that relate to the title, border, and menu areas of a window, typically those areas that are managed by the operating system, not the application), MDI (Multiple Document Interface) messages, and many other types. These categories are somewhat inexact, not always strictly defined; they simply serve as a tool of convenience for programmers trying to form a mental picture of the large set of window management messages. Nor is the set of WM_ messages fixed; it is constantly growing as new operating system capabilities are added.

Other message groups are related to specific window types. There are messages defined for edit controls, buttons, listboxes, combo boxes, scrollbars, list and tree views, and so on. These messages, with few exceptions, are typically processed by the window procedure of the control's window class and are rarely of interest to the application programmer.

Applications can also define their own messages. Unique message identifiers can be obtained through a call to the function RegisterWindowMessage. Using private message types enables parts of an application to communicate with each other; separate applications can also exchange information this way. In fact, in 16-bit Windows, cooperating applications typically exchanged data by sending handles of global memory objects to each other. In Win32, this mechanism does not work because applications no longer share an address space; however, other, more powerful mechanisms (for example, memory mapped files) are available for intertask communication.