User-defined class response custom message in MFC

This technical article is not a discussion of the classical MFC of the message working mechanism, the discussion of how the message works, ways and paths are everywhere in the Internet and books. Many of the discussions on the web are about how to respond to user-defined message mappings; There are also articles on the web that describe how to respond to Windows messages in custom classes, as described in this article. However, most of the articles on the web do not have a thorough exposition of how to respond to custom messages in a user-defined class in a common way.

The problem is defined as follows: The user defines a class that does not necessarily have an interface (which can be completely invisible) and requires a custom class to respond to a custom message.

Classes that can respond to a message first must be derived from the CCmdTarget class, because only the framework and processing mechanisms that provide the message in this class are derived from the CWnd class. CWinApp class, CDocument class, CDocTemplate class are all derived classes of cmdtarget, that is, subclasses, and CFrameWnd classes, CView classes, CDialog classes, etc. are derived from CWnd, It is also the offspring of CCmdTarget, so they are able to respond to messages, but the types of response messages are not the same. So, if the class that you define requires a response to a command message (that is, WM_COMMAND, a message in a menu, a toolbar, including a shortcut key, this type of message processing mechanism differs from other message-handling mechanisms that start with wm_, which has a well-defined message flow path). Then the custom class can be derived from the CCmdTarget. Because the CWnd form class derives from the CCmdTarget parent class, a class derived from CWnd can also respond to a command message, as a result. This kind of command message, whether it is added to some existing classes such as the CWinApp class or a custom class, is a very easy thing to do, simply by using the wizard, which is no longer described here.

If a user-defined class requires a response to a normal Windows message (that is, a message other than WM_COMMAND, except for the WM_, the message below Wm_user is the system message, Wm_user above can be defined by the user), That requires that the custom class must derive from CWnd. This is due to the processing mechanism of such messages, which do not have the tedious flow path of the command message, but the message issuer directly to the corresponding CWnd form handle, which is responsible for the response of the message by CWnd. So this type of message must correspond to a CWnd class, more precisely a form handle that must be associated with an HWND type. This concludes with an important conclusion that classes derived from CCmdTarget that do not derive from CWnd do not have the ability to handle such messages.

In summary, this is why command messages can be processed in most classes, including CWinThread, CWINAPP, CDocument, CView, CFrameWnd, or custom classes, Ordinary Windows messages and user-defined messages can only be processed in classes derived from CFrameWnd and CView such as CWnd.

Thus, our custom classes can only derive from CWnd in response to custom messages (of course, classes that do not respond to any message may derive from CObject). Let's take a look at how to customize the message:

Work done in. h:

The first step is to declare the message:

#define Wm_mymsg wm_user+8

The second step is to declare the message map in the class declaration:

Declare_message_map ()

The third step is to define the message handler function in the class declaration:

afx_msg LRESULT Mymsghandler (Wparam,lparam);

Work done in. cpp:

The fourth step is to implement the message map:

Begin_message_map (CMainFrame, CMDIFrameWnd) on_message (Wm_mymsg,onmymsghandler) End_message_map ()

The fifth step is to implement the message handler function (which can, of course, not be implemented):

LRESULT Cmainframe::onmymsghandler (WPARAM w,lparam l) {AfxMessageBox ("hello,world! "　　);  return0;}

Only write in the place where the message was raised or sent:

:: Sendmessge (:: AfxGetMainWnd ()->m_hwnd,wm_mymsg,0,0);

In this case, the custom message is complete, this is a lot of online articles are written about things. You will find that the above code is implemented in the CMainFrame class, but it is not as easy to use a custom class. Obviously replacing the cmainframe of the fourth and fifth steps with a custom class name (where I'm using Cmytestobject to represent a custom class) is not working properly. The reason is that the first parameter in the SendMessage function that sends the message is the form handle of the HWND type that corresponds to the message, and the m_hwnd in the Cmytestobject class has no meaning until cwnd::create is called. That is, when the CWnd::Create or Cwnd::createex function is not called, CWnd does not correspond to any form, and message processing does not work properly.

So, another important conclusion is to make sure that the m_hwnd is associated to a form, even if the form is not visible, before the custom class can handle any message. Then some people say that it is OK to call the CREATE function in the constructor of the custom class, yes, and of course it can be called elsewhere, just make sure before the message is sent. However, the call to create is very much, note two places, the first parameter is the name of the class, I recommend the best set to NULL, the fifth parameter is a pointer to the parent form object, this function specifies the object must exist, I recommend the best for the whole program of the main form. There are a lot of people who ask the meaning of the sixth parameter, which is not very relevant, is the subform ID, which is passed to the parent form record for identification. Here is the constructor for my custom class:

Cmytestobject::cmytestobject () {cwnd::create (NULL,"Mytestobject", Ws_child,crect (0,0,0,0),:: AfxGetMainWnd (),1234);} //be sure to use after you build the main form, after the main form finishes processing the OnCreate messageCmytestobject::cmytestobject (CWND *pparent) {cwnd::create (NULL,"Mytestobject", Ws_child,crect (0,0,0,0), Pparent,1234);}

Create cannot be called as follows because Cmytestobject does not associate any forms at this time, so the m_hwnd in this is not valid:

CWnd::Create (NULL,"mytestobject", Ws_child,crect (0,0,0, 0),This,1234);

Then the above four or five two steps are modified to:

Begin_message_map (Cmytestobject, CWnd) on_message (Wm_mymsg,onmymsghandler) end_message_map () LRESULT Cmytestobject::onmymsghandler (WPARAM w,lparam l) {AfxMessageBox ("my Messge Handler in my Self-custom Class! "　　);  return0;}

To send a message outside the class:

Cmytestobject *test=New  cmytestobject ();:: SendMessage (Test->m_hwnd,wm_mymsg,0, 0);

To emit a message in a member function (method) inside a class:

:: SendMessage (M_hwnd,wm_mymsg,0,0);

The last problem is the form recycling that is prone to warning errors, and the custom class to explicitly call the form to destroy, the destructor is as follows:

cmytestobject::~Cmytestobject () {CWnd::D Estroywindow ();}

User-defined class response custom message in MFC