In-depth WM_COMMAND command message delivery in MFC

MFC has a high degree of abstraction and encapsulation of the Windows Messaging system, the fundamental principle of which is to use the advanced features of C + + and combine certain design patterns (such as Factory mode, template method, etc.) to achieve. General Windows messages (WM_XXX), it must be from the derived class flow to the base class, without the possibility of a side stream. If it is a command message (WM_COMMAND), then there is a more peculiar route. The following is a discussion of the WM_COMMAND message delivery process for multi-document/single-document (Document-view), Dialog-box application comparison. Before discussing the source of the command message, the command message is typically the user chooses a menu item, or an accelerator key is translated, or a child control sends a notification message to its parent window when it is generated. For a menu, the message receiver is the frame window or the dialog box that owns it; for a toolbar, the message receiver is its parent window. The two application command message processing flows are as shown.

    It is known that the document view type of processing route is first down and upward, and the dialog-type alignment is always upward, the message receiver only one, and the handler order has multiple, Each processor inside the first is called the base class CCmdTarget oncmdmsg virtual function, in this function step to the basic Class traversal message map table, according to the command ID and notification code to find the corresponding message map structure afx_msgmap_entry, if found to process the command message , otherwise returns false, returning to the OnCmdMsg function where this object is located for next processing. If no message map for the corresponding command is found to the last level, the default processing DefWindowProc is returned to the system. In a comprehensive consideration, if a dialog box receives a command message, such as clicking on a button on its child controls toolbar, and the dialog class does not add the corresponding On_command map, it will go into its parent window class OnCmdMsg function to handle, If the parent window is exactly the frame window, then the process of the command message is transferred from the right to the left. If the final command message can be processed, see if 5 objects (Frame, View, Document, Dialog, APP, Thread) have the corresponding On_command mappings added. So far, we have clarified the process of WM_COMMAND message processing, but found that the final processing is passed by the window to receive the message, not the message notifier himself, sometimes in order to improve the encapsulation of the code, you may need to handle these commands more convenient, For example, there is a toolbar Cplaytoolbar subclass inherits from CToolBar, there are 3 buttons to play, pause, stop, and its parent window is the Cplaydialog dialog box. As a rule, the handling of these 3 button command events is typically 3 ON_COMMAND mapping macros and handlers in the Cplaydialog class, but if 3 on_command map macros and handlers are added to the Cplaytoolbar class, they are not processed. The reason is that the dialog-type line is always up, and there is no corresponding command in MFC reflection ON_COMMAND_REFLECT this macro. In order for the Cplaytoolbar class to handle the 3 button command events itself, it is necessary to transfer the route from the Cplaydialog class to its child window toolbar so that the Cplaytoolbar class gets the chance to handle it. The action is to overload the OnCommand virtual functions of Cplaytoolbar and Cplaydialog, and the   cplaydialog code is as follows:

 1BOOL Cplaydialog::oncommand (WPARAM WPARAM, LPARAM LPARAM)
2  {
3         if(LParam==(LPARAM) M_playtoolbar.m_hwnd)
4        {
5 M_playtoolbar.   OnCommand (Wparam,lparam); //m_playtoolbar is the Cplaytoolbar object, notice that OnCommand becomes a public member
6}
7       Else
8       {
9 return cdialog::oncommand (WParam, LParam);
ten }
One}

The Cplaytoolbar class code looks like this:

1 Begin_message_map (Cplaytoolbar, CToolBar)
2on_command (Id_play, PLAY)
3on_command (Id_pause, PAUSE)
4on_command (Id_stop, STOP)
5 End_message_map ()
6
7voidCplaytoolbar: Lay:P ()
8    {
9 }
TenvoidCplaytoolbar::P ause ()
One   {
-- }
-   voidCplaytoolbar::stop ()
-   {
}

Now, 3 button command events can be handled independently in the Cplaytoolbar class, which improves the encapsulation of the code and simplifies the processing of the parent window Cplaydialog class

In-depth WM_COMMAND command message delivery in MFC