Chapter 6: Handling Messages
This chapter describes how MFC processes messages and explains how to connect messages to their corresponding handler functions using the ClassWizard and WizardBar tools.
While there are many different types of messages, this chapter focuses on Windows messages (those generated by the Microsoft Windows operating system) and command messages (those coming from user interface objects, such as menus, toolbar buttons, and accelerator keys). Other types of MFC messages are also briefly introduced.
After completing this chapter, you will be able to:
® Define what a message is in the Windows operating system.
® List the types of Microsoft Foundation Class (MFC) Library messages.
® Describe the purpose and benefits of message maps.
® Declare and implement a message map.
® Describe how messages are processed by the MFC framework.
® Create the framework for a simple MDI application.
® Use ClassWizard and the WizardBar to add or delete an event's message handler.
® Implement a handler member function.
® Add a message box to a handler function to provide information to the end user.
Introduction to Messages
Messages are the primary way that MFC applications are notified of events; they are central to the event-driven programming model used in the Windows operating system. The purpose of messages is to notify your application that an event has occurred. The application's behavior is defined by how it responds to a message.
MFC applications process Windows messages much as any other application for Windows does. But MFC simplifies and enhances the Windows message handling functionality by using a message mapping system and the command target class, CCmdTarget.
This section explores the types of messages generated by the Windows operating system and introduces the message mapping system used in MFC applications. This section includes the following topics:
® Types of Messages
® Message Maps
® Message Mapping vs. Virtual Functions
For a complete list of standard Windows messages, see the Visual C++ online book, Win32 Programmer's Reference, "Volume 5: Messages, Structures, and Macros."
- Types of Messages
Communication between the operating system, applications, and application components is conducted through various types of messages. For example, when creating an instance of an application, the operating system will send a series of messages to the application, which will then respond appropriately to initialize itself. Keyboard and mouse activity will cause the operating system to generate messages and send them to the proper application. User-interface components, like command buttons and list boxes, will generate messages and send them to their parent windows.
MFC extends and organizes the concept of messages by dividing them into the following categories:
® Windows messages
® Command messages
® User interface update command messages
® Event-notification messages
® Custom control messages
® System-registered messages
® User-defined messages
This topic focuses primarily on the first two types of messages: Windows messages and command messages.
Windows Messages
Windows messages are generally defined as those messages generated by the Windows operating system. They inform the application about window creation, impending window destruction, mouse and keyboard events, changes to the system default colors, and anything else that may impact the operation of the application. For example, one of the most important messages is WM_PAINT. This message is sent by Windows to an application window to indicate that a portion of the window's drawing area needs repainting.
A very important fact is that Windows messages are sent to the window and can only be handled by a window object. These messages are not routed to other classes for processing.
Command Messages
Command messages are generated by the user when selecting menu items, clicking toolbar buttons, or pressing shortcut keys (accelerator keys). Whenever one of these events occurs, a WM_COMMAND or WM_message containing command-specific information is sent to the application.
In contrast to Windows messages, command messages get routed to various application objects or classes for processing. This allows your application to handle the message in the class most closely associated with the message.
User Interface Update Command Messages
User interface update command messages are created within an application by the application framework; that is, they are MFC specific. They signal the application to update the state of user-interface elements such as menu items, toolbar buttons, and status-bar panes. For example, before a menu is displayed, the application framework will send the application an appropriate update command message that gives it an opportunity to modify the menu item state (i.e., enabled/disabled/grayed/checked) based upon the current status of the application.
Event Notification Messages
Event notification messages are sent from a child common-control window to its parent. For example, when the user types a character in an edit box, the edit box control sends an EN_UPDATE message to the parent window (usually a dialog box). This notifies the parent window that its contents are about to change.
Custom Control Messages
Custom control messages are similar to event notifications, but are used by custom controls to send messages to their owner window — usually a dialog box. One of the best examples of this is the WM_CTLCOLOR message. This message is sent to a parent to allow it to become involved in the control's painting process.
System-Registered Messages
The Windows messaging system can be extended by the creation of new program-defined messages that are registered with the operating system at run time. These system-registered messages are available to all applications.
User-Defined Messages
A user-defined message is any message that is not a standard Windows message. By creating a user-defined message (as opposed to using a function call), you can take advantage of the Microsoft Windows messaging system.
Although not commonplace in an MFC application, a window object can define its own private messages to allow other objects to communicate with it through the Windows messaging system. Message numbers that begin with the WM_USER value (0X400) are designed for this purpose.
In general, a window object provides access functions instead of using these private messages.
- Message Maps
A message map is a table that correlates messages with the member functions an application provides to handle those messages. Each entry in the table consists of a message-specific macro. Message maps are used to handle both Windows messages and command messages.
What MFC does internally to implement message maps is hidden behind some fairly complex macros and processes. However, creating and using a message map is a simple process. In fact, most of the work is done for you by AppWizard. Here are the steps to add a message map to a class:
1. Declare the message map by adding a DECLARE_MESSAGE_MAP statement to the class declaration. AppWizard adds this code to the header file, xxx.h.
2. Create and initialize the message map by placing message map macros identifying the messages that the class will handle between the statements BEGIN_MESSAGE_MAP and END_MESSAGE_MAP. AppWizard adds this code near the beginning of the implementation file, xxx.cpp.
3. Add member functions to the implementation file to handle the messages.
Example of a Message Map
The following is an example of a message map for the view class CMyView.
BEGIN_MESSAGE_MAP(CMyView, CView)
ON_WM_CREATE()
ON_COMMAND(ID_APPLY_SEQUENCE, OnApplySequence)
END_MESSAGE_MAP()
This message map has two entries: one to handle the Windows message WM_CREATE, and one to handle the command message, ON_COMMAND. The BEGIN_MESSAGE_MAP macro includes the base class CView as one of its arguments so that the framework can continue searching for a given handler if one does not exist within the derived class.
No comments:
Post a Comment