Windows is a message-based environment. In the familiar MS-DOS programming world, your program calls the operating system. In Windows, the operating system (Windows) sends a message to your program. The “program” is associated with a particular window, and the message might be “destroy yourself,” “repaint yourself,” “your child button was pushed,” or something similar.
Your program might also send a message to Windows. These “outbound” messages are often directed at a child window, such as a button, list box, or edit control, that has inaccessible code. If, for example, you send a “scroll” message to an edit control, Windows itself does the work. Your application program cannot intercept these outbound messages once they are sent.
The C++ language naturally accommodates the messaging behavior of Windows. Objects receive messages through the “member functions” of their class, and they send messages by calling a member function for another object. A C++ object represents a Windows window, and the member functions of the class process individual messages. The OnPaint member function of a derived window class, for example, receives and processes a Windows WM_PAINT message. The CListBox member function AddString sends an LB_ADDSTRING message to Windows.
The real magic of the Windows Foundation classes begins here. There is no longer any “program logic flow” as in conventional procedural programming. Each window object is self-sufficient and is responsible for (1) acting on the messages that are important to it and (2) sending messages to other window objects. It can create and delete other windows along the way. The interaction among window objects, and thus the flow of the program, is governed by the actions of the end user rather than by complex code and data structures.
In native Windows,, the WndProc function processes a particular window's incoming messages. The message ID is a WndProc function parameter that is decoded with a case statement. The ID is compared to a list of expected codes defined as constants in WINDOWS.H. Each message has two “message parameters,” wParam (two bytes) and lParam (four bytes),, that are also WndProc parameters. The meaning of wParam and lParam depends on the message type. These message parameters can be pointers to structures or functions or they can be composites of flags and fields. The WndProc program must decode the messages appropriately.
Outbound messages are sent to Windows and to other windows through several “send message” functions. The WndProc program must encode the message parameters for these outbound messages.
The Microsoft Foundation classes replace the case statement and parameter decoding for incoming messages with class member functions. These member functions are linked to a structure called a “message map” that governs translation of the message parameters. The message map is described later in this chapter,, in “Notification Messages and the Message Map,” on page 13.