User-Defined class response custom message in MFC

First, all classes that can respond to messages must be derived from the csf-target class, because only the classes provide the message framework and processing mechanism, and the cwnd class also derives from this class. The cwinapp, cdocument, and cdoctemplate classes are all derived classes of csf-target, that is, subclasses. The cframewnd, cview, and cdialog classes are derived from cwnd and are actually descendants of csf-target, therefore, all messages can be responded to, but the types of response messages are not the same.

If your defined class requires a response to the Command Message (that is, wm_command, that is, messages in some menus and toolbar, including shortcut keys, this type of message processing mechanism is different from other message processing mechanisms starting with WM _. It has a clear level of Message Flow Path), so the custom class can be derived from c1_target. Since the cwnd form class is derived from the csf-target parent class, the class derived from cwnd can also be taken as the response command message. This type of command message is easy to add to existing classes, such as cwinapp or custom classes. You only need to use the wizard and will not describe it here.

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 form handle of the corresponding cwnd by the message sender. The cwnd is responsible for the response of the message. 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 to respond to the hwnd type form handle of the message, while the m_hwnd in the cmytestobject class does not call cwnd :: there is no meaning before create, that is, when the cwnd: Create or cwnd: createex function is not called, 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 the constructor of my custom class:

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 ();
}

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/yuwei19840916/archive/2008/12/04/3445659.aspx