The difference and connection between ON_MESSAGE, ON_COMMAND and ON_NOTIFY

This article is reproduced from: The difference and connection of ON_MESSAGE, ON_COMMAND and ON_NOTIFY



      ON_COMMAND is a macro that handles messages for menus and toolbar items

      ON_MESSAGE is a macro that processes custom messages

      ON_NOTIFY is a macro for the control to send a message to its parent window



      To understand these messages, you must first understand the background of the Window message.
      In Windows 3.1, the control will notify its parent window of messages such as mouse, keybord, etc. The only messages used are WM_COMMAND, event type and control ID are contained in wParam, and the handle of the control is contained in lParam. Since wParam and lParam are full, when the control wants to send other special messages to the parent window with a lot of information attached, there is no place to store them. Therefore, many other message types are defined in Windows 3.1, such as WM_VSCROLL, WM_CTLCOLOR, etc. The information attached to each message wParam, lParam is different.
      When it comes to Win32, there are more and more types of controls. Of course, you cannot define a set of messages for each control, which is not conducive to the expansion of the system. So the only powerful message WM_NOTIFY is defined in Win32. Of course, WM_NOTIFY also obeys the original message rules, that is, it only takes parameters wParam and lParam. The only difference is that an NMHDR pointer is transmitted in lParam at this time. Different controls can expand NMHDR according to the rules, so the amount of information transmitted by the WM_NOTIFY message can be quite large. This can be seen in the relevant description in MSDN. There are many such messages in TreeControl.

      Now you can see why there are ON_MESSAGE, ON_COMMAND, and ON_NOTIFY.
      ON_MESSAGE handles all Windows messages, because all messages are transmitted in the same format, that is, ID, WPARAM, LPARAM.
      ON_COMMAND is dedicated to processing WM_COMMAND messages, so we don't have to unlock the control IDs and event types transmitted in wParam and lParam in WM_COMMAND.
      Needless to say ON_NOTIFY, see if his processing function can solve NMHDR.

      This is the same at a glance. Both ON_COMMAND and ON_NOTIFY can be processed with ON_MESSAGE, but they have to do a lot more. ON_COMMAND and ON_NOTIFY are best not interchanged!



      A few notes:

      1.ON_COMMAND (id, memberFxn)
      This macro inserts a message map through ClassWizard or manually. It indicates that that function will process a command message from a command user interface (such as a menu item or toolbar button). When a command object receives a Windows WM_COMMAND message through the specified ID, ON_COMMAND will call the member function memberFxn to process this message. In the user's message map, there should indeed be an ON_COMMAND macro statement for each menu or accelerator command (must be mapped to a message processing function).

      2.ON_MESSAGE (message, memberFxn)
      Indicates which function will process a user-defined message. User-defined messages are usually defined in the range WM_USER to 0x7FF. User-defined messages are any messages that are not standard Windows WM_MESSAGE messages. In the user's message map, each must be mapped to a message processing function. User-defined messages should have an ON_MESSAGE macro statement.

      3.ON_Update_COMMAND_UI (id, memberFxn)
      This macro is usually inserted into a message map via ClassWizard to indicate which function will handle a user interface change command message. In the user's message mapping, each user interface change command (become mapped to a message processing function) should have an ON_Update_COMMAND_UI macro statement.

      4.ON_VBXEVENT (wNotifyCode, memberFxn)
      This macro is usually inserted into a message map via ClassWizard to indicate which function will process a message from VBX control. There should be a macro statement for each VBX control message mapped to a message processing function in the user's message map.

      5.ON_REGISTERED_MESSAGE (nmessageVarible, memberFxn)
      The Windows RegisterWindowsMesage function is used to define a new window message. This message is guaranteed to be unique in the entire system. This macro indicates which function processes a registered message. The variable nMessageViable should be defined with the NEAR modifier.

      6.ON_CONTROL (wNotifyCode, id, memberFxn)
      Indicates which function will process a regular control presentation message. Control identification messages are those messages sent from a control character to the parent window.