How does MFC add custom messages and their response functions?

If the user-defined class requests to respond to common Windows messages (that is, messages starting with WM _ Except wm_command), such messages are system messages below wm_user, wm_user and above can be defined by the user), then the custom class must be derived from cwnd. This is determined by the processing mechanism of such messages. Such messages do not have the tedious Flow Path of the command message, but are directly sent to the corresponding message sender.

The form handle of cwnd. cwnd is responsible for message response. Therefore, such messages must correspond to the same cwnd class. More specifically, they must correspond to an hwnd type form handle. In this way, an important conclusion is that the class derived from cve-target without cwnd does not have the ability to process such messages.

To sum up, it is why command messages can be stored in most classes for processing, including cwinthread, cwinapp, cdocument, cview, cframewnd, or custom classes, while common Windows messages and user-defined messages can only be placed in cframewnd, cview, and other derived and cwnd classes for processing.

It can be seen that a custom class can only be derived from cwnd to respond to a custom message (of course, classes that do not respond to any message can be derived from cobject ). Let's take a look at how to customize messages:

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 ing in the class declaration:

Declare_message_map ()

Step 3: Define the message processing function in the class declaration:

Afx_msg lresult mymsghandler (wparam, lparam );

The work done in. cpp:

Step 4: Implement Message ing:

Begin_message_map (cmainframe, cmdiframewnd)

On_message (wm_mymsg, onmymsghandler)

End_message_map ()

Step 5: implement the message processing function (of course not ):

Lresult cmainframe: onmymsghandler (wparam W, lparam L)

{

Afxmessagebox ("Hello, world! ");

Return 0;

}

Only write the following when a message is triggered or sent:

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

At this point, the custom message is complete, which is something many online articles have written. You will find that the above Code is implemented in the cmainframe class, but it is not that simple if you want to use a custom class. Obviously, changing the cmainframe in step 4 and Step 5 to the custom Class Name (here I use cmytestobject to represent the custom class) cannot work normally. The reason is that the first parameter in the sendmessage function for sending a message is

The form handle of the hwnd type corresponding to the response message. In the cmytestobject class, m_hwnd has no meaning before cwnd: Create is called, that is, cwnd: is not called :: when the create or cwnd: createex function is used, cwnd does not correspond to any form, and message processing cannot work properly.

Therefore, another important conclusion is that before a custom class can process any message, make sure that m_hwnd is associated with a form, even if the form is invisible. Some people say that it is fine to call the create function in the constructor of the custom class. Of course, it can also be called elsewhere, as long as it is ensured before the message is sent. However, there are many sayings about the create call. Note that the first parameter is the class name. We recommend that you set it to null. The fifth parameter is the pointer to the parent form object, the objects specified by this function must exist. It is recommended that they be the main form of the entire program. There are also many people who ask about the sixth parameter, which has little to do with it. It is a child form ID, which is used to pass to the parent form record for identification. The following is my

User-Defined class constructor:

Cmytestobject: cmytestobject ()

{

Cwnd: Create (null, "mytestobject", ws_child, crect (1234,),: afxgetmainwnd );

} // It must be used after the main form is generated. After the oncreate message is processed in the main form

Cmytestobject: cmytestobject (cwnd * pparent)

{

Cwnd: Create (null, "mytestobject", ws_child, crect (0, 0, 0), pparent, 1234 );

}

Create cannot be called as follows, because cmytestobject is not associated with any form at this time, m_hwnd in this is invalid:

Cwnd: Create (null, "mytestobject", ws_child, crect (1234,), this );

In this case, step 4 and Step 5 are changed:

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! ");

Return 0;

}

Send a message outside the class:

Cmytestobject * test = new cmytestobject ();

: Sendmessage (test-> m_hwnd, wm_mymsg, 0, 0 );

Send a message in a member function (method) within the class:

: Sendmessage (m_hwnd, wm_mymsg, 0, 0 );

The last problem is the form recycling that generates warning errors. The custom class must explicitly call the form destruction. The Destructor is as follows:

Cmytestobject ::~ Cmytestobject ()

{

Cwnd: destroywindow ();

}