Dewsoft Frontpage Tutorials

Lesson - 3:Messages and Commands

3.1 : Understanding Message Routing

If there is one thing that sets Windows programming apart from other kinds of programming, it is messages. Most DOS programs, for example, relied on watching (sometimes called polling) possible sources of input like the keyboard or the mouse to await input from them. A program that wasn’t polling the mouse would not react to mouse input. In contrast, everything that happens in a Windows program is mediated by messages. A message is a way for the operating system to tell an application that something has happened—for example, the user has typed, clicked, or moved the mouse, or the printer has become available. A window (and every screen element is a window) can also send a message to another window, and typically most windows react to messages by passing a slightly different message along to another window. MFC has made it much easier to deal with messages, but you must understand what is going on beneath the surface.

Messages are all referred to by their names, though the operating system uses integers to refer to them. An enormous list of #define statements connects names to numbers and lets Windows programmers talk about WM_PAINT or WM_SIZE or whatever message they need to talk about. (The WM stands for Window Message.) An excerpt from that list is shown in Listing 3.1.

Listing 3.1 Excerpt from winuser.h Defining Message Names

#define WM_SETFOCUS 0x0007

#define WM_KILLFOCUS 0x0008

#define WM_ENABLE
0x000A

#define WM_SETREDRAW 0x000B

#define WM_SETTEXT
0x000C

#define WM_GETTEXT 0x000D

#define WM_GETTEXTLENGTH 0x000E

#define WM_PAINT 0x000F

#define WM_CLOSE 0x0010

#define WM_QUERYENDSESSION 0x0011

#define WM_QUIT 0x0012

#define WM_QUERYOPEN 0x0013

#define WM_ERASEBKGND
0x0014

#define WM_SYSCOLORCHANGE 0x0015

#define WM_ENDSESSION 0x0016

As well as a name, a message knows what window it is for and can have up to two parameters. (Often, several different values are packed into these parameters, but that’s another story.)

Different messages are handled by different parts of the operating system or your application. For example, when the user moves the mouse over a window, the window receives a WM_MOUSEMOVE message, which it almost certainly passes to the operating system to deal with. The operating system redraws the mouse cursor at the new location. When the left button is clicked over a button, the button (which is a window) receives a WM_LBUTTONDOWN message and handles it, often generating another message to the window that contains the button, saying, in effect, "I was clicked."

MFC has enabled many programmers to completely ignore low-level messages such as WM_MOUSEMOVE and WM_LBUTTONDOWN. Instead, programmers deal only with higher level messages that mean things like "The third item in this list box has been selected" or "The Submit button has been clicked." All these kinds of messages move around in your code and the operating system code in the same way as the lower level messages. The only difference is what piece of code chooses to handle them. MFC makes it much simpler to announce, at the individual class’s level, which messages each class can handle. The old C way, which you will see in the next section, made those announcements at a higher level and interfered with the object-oriented approach to Windows programming, which involves hiding implementation details as much as possible inside objects.

Next>>