Message Handling in MFC

Introduction Message Maps are the way by which MFC handles the Application messages. Any class which is derived from CCmdTarget is a candidate for handling messages. Previously in win32, a programmer is supposed to handle all messages posted to the message loop. To the relief of all MFC has relieved the programmers from all these pains and allows programmers just to restrict themselves with the functionality implementations.

Message Map The association between a particular message and the function in your program that is to service it is established by a message map . Each class in your program that can handle Windows messages contains a message map. A message map for a class is simply a table of member functions that handle Windows messages. Each entry in the message map associates a particular message with a function; when a given message occurs, the corresponding function will be called. Only the messages that are relevant to a class will appear in the message map for the class. A message map for a class is created automatically by AppWizard, or by ClassWizard when you add a class that handles messages to your program. The start of a message map in is indicated by a BEGIN_MESSAGE_MAP() macro The end is marked by an END_MESSAGE_MAP() macro.

In our MDI program, Sketcher, a message map will be defined for each of the classes CSketcherApp, CSketcherDoc, CSketcherView, CMainFrame and CChildFrame.

You can see the message map for a class in the You can see the message map for a class in the .cpp file that contains the implementation of the class. The functions that are included in the message map also need to be declared in the class definition, but they are identified here in a special way. class CSketcherApp : public CWinApp{ public: CSketcherApp(); virtual BOOL InitInstance(); //}}AFX_VIRTUAL Implementation //{{AFX_MSG(CSketcherApp) afx msg void OnAppAbout(); // NOTE - the ClassWizard will add and remove memberfunctions here. // DO NOT EDIT what you see in these blocks of generated code ! //}}AFX_MSG DECLARE_MESSAGE_MAP() };

afx_msg void OnAppAbout(); declares a message handlers The macro DECLARE_MESSAGE_MAP() indicates that the class can contain function members that are message handlers. In fact, any class that you derive from the MFC class CCmdTarget can potentially have message handlers, so such classes will have this macro included as part of the class definition by AppWizard or ClassWizard, depending on which was responsible for creating it. If you are adding your own members to a class directly, it's best to leave the DECLARE_MESSAGE_MAP() macro as the last line in the class definition. If you do add members after DECLARE_MESSAGE_MAP(), you'll also need to include an access specifier for them: public, protected or private. If a class definition includes the macro DECLARE_MESSAGE_MAP(), the class implementation must include the macros BEGIN_MESSAGE_MAP() and END_MESSAGE_MAP().

The message map knows which menu or key is pressed, by the identifier (or ID) that's included in the message. The ON_COMMAND() macro ties the function name to the command specified by the ID. Thus, when a message corresponding to the identifier is received, the corresponding function is called. The BEGIN_MESSAGE_MAP() macro has two arguments. The first argument identifies the current class name for which the message map is defined and the second provides a connection to the base class for finding a message handler. If a handler isn't found in the class defining the message map, the message map for the base class is then searched. The command IDs such as ID_APP_ABOUT are standard IDs defined in MFC correspond to messages from standard menu items and toolbar buttons. The prefix ID_ is used to identify a command associated with a menu item or a toolbar button ID_FILE_NEW is the ID that corresponds to the File | New menu item being selected, and ID_APP_ABOUT corresponds to the Help | About menu option.

Message Categories Windows messages Control notifications There are three main categories: Windows messages Includes primarily those messages beginning with the WM_ prefix, except for WM_COMMAND. Windows messages are handled by windows and views. These messages often have parameters that are used in determining how to handle the message. Control notifications Includes WM_COMMAND notification messages from controls and other child windows to their parent windows. For example, an edit control sends its parent a WM_COMMAND message containing the EN_CHANGE control-notification code when the user has taken an action that may have altered text in the edit control. The window's handler for the message responds to the notification message in some appropriate way, such as retrieving the text in the control. Command messages Includes WM_COMMAND notification messages from user-interface objects: menus, toolbar buttons, and accelerator keys. The framework processes commands differently from other messages, and they can be handled by more kinds of objects, as explained in Command Targets.

The first two categories of message that is, standard Windows messages and control notification messages are always handled by objects of classes derived from CWnd. Frame window classes and view classes, for example, are derived from CWnd, so they can have member functions to handle Windows messages and control notification messages. Application classes, document classes and document template classes are not derived from CWnd, so they can't handle these messages. Handling command messages is much more flexible. You can put handlers for these in the application class, the document and document template classes, and of course in the window and view classes in your program.

How Command Messages are Processed All command messages are sent to the main frame window for the application. The main frame window then tries to get the message handled by routing it in a specific sequence to the classes in your program. If one class can't process the message, it passes it on to the next. For an SDI program, the sequence in which classes are offered an opportunity to handle a command message is: 1. The view object 2. The document object 3. The document template object 4. The main frame window object 5. The application object If none of the classes has a handler defined, default Windows processing takes care of it.

The sequence for routing a command message in an MDI program is: 1. The active view object 2. The document object associated with the active view 3. The document template object for the active document 4. The frame window object for the active view 5. The main frame window object 6. The application object It's possible to alter the sequence for routing messages, but this is so rarely necessary