Messages and Event-Driven Programming

In its simplest form, message-driven programming (also known as event-driven programming) is a process by which various subprocesses and/or applications communicate. In Windows, messages are the process used by Windows itself to manage a multitasking system and to share keyboard, mouse, and other resources by distributing information to applications, application instances, and processes within an application.

Thus, under Windows, instead of applications receiving information directly from the keyboard or the mouse driver, the operating system intercepts all input information, packaging this information using the MSG message structure (detailed in the following section) and then forwarding the prepared messages to the appropriate recipients. In turn, the recipient applications use TranslateMessage for application-specific interpretation (particularly accelerator-key assignments) before calling DispatchMessage to forward individual traffic items to their appropriate handlers.

Furthermore, the process described is not limited to keyboard and mouse events. Instead, this includes all input devices (including ports), as well as messages generated by application child and subprocesses, Windows timers, or, quite frequently, by Windows itself.

NOTE

Abstract descriptions of message-driven programming provide only a theoretical outline without really illustrating how these processes function. Therefore, a fuller explanation will be left until subsequent examples in this book can provide both hands-on experience as well as practical illustrations (beginning, of course, with messages processed by the WinHello demo).

But before we get to how messages are transmitted, let’s take a look at the message record structure and how messages are organized.

The Message Record Structure

The MSG (message structure) record type is defined in WinUser.H as:

typedef struct tagMSG
{  HWND    hwnd;
   UINT    message;
   WPARAM  wParam;
   LPARAM  lParam;
   DWORD   time;
   POINT   pt;   } MSG, *PMSG, NEAR *NPMSG, FAR *LPMSG;

NOTE

Both the NEAR and FAR types are essentially obsolete in 32-bit systems. Originally, NEAR meant an address within a 16KB block, and FAR indicated an address outside the “local” 16KB address space. Today, all addresses are NEAR without requiring the specification, and specifying FAR is obsolete. However, there are no penalties or conflicts arising for continuing to use FAR, and this term does continue to appear in many structure and function definitions, as in the MSG definition shown here.

The POINT data type is defined in WinDef.H as:

typedef struct tagPOINT
{  int  x;
   int  y; } POINT, *PPOINT, NEAR *NPPOINT, FAR *LPPOINT;

The message-event fields defined are used as:

hwnd The handle of the specific window to which the message is directed.
message A 16-bit value identifying the message. Constants corresponding to all message values are provided through Windows.H and begin with the WM_ (which stands for “window message”) prefix. For example, a mouse-button event message might be identified by the constant WM_LBUTTON_DOWN (left button pressed).
wParam A 32-bit (double word) message parameter. The value format and meaning depend on the primary event message type. Variously, the wParam argument might convey a coordinate point pair, use the low-word value to identify a secondary message type, provide some other type of data, or be ignored entirely. In many cases, the wParam value will be treated as two separate word values with different functions.
lParam A 32-bit (long) message parameter. The value and meaning of this parameter depends on the primary event message type. Variously, the lParam argument might provide a pointer to a string or record structure; break down as a group of word, byte, or flag values; or, quite frequently, be completely unused.
time A double word value that identifies the time the message was placed in the message queue.
pt The mouse coordinates at the time the message was placed in the message queue (irrespective of the message event type or origin).

Note that these last two fields, time and pt, are not passed to the WndProc procedure. Instead, these two fields are used only by Windows, principally to resolve any conflict over the order of events and, of course, to determine where a specific event should be addressed.

NOTE

Each application is itself composed of a series of separate windows. These windows include the frame, the caption bar, the system menu, and minimize and maximize buttons, as well as the application’s main display, which is referred to as the client window or, occasionally, the display window. Normally, only messages directed to the client window will be forwarded by the DispatchMessage procedure to the application’s WndProc procedure. Messages directed to other application windows are generally handled indirectly (by Windows 98), even though this may result, in turn, in further messages being sent to the client window.