In the above example, CDerived was born from CBase. CDERIVED class changes the window of the window represented by the CBASE class by defining a WM_LBUTTONDOWN message processing function.
Thus, the message map of the CBase class defines a processWindowMessage () function, and the CDeriveD class message map also defines a processWindowMessage () function.
So, how do we connect these two classes in the logic logic? (Think about why you want to connect?)
In CDeriveD's message map, there is a macro chain_msg_map (). Its role is to connect two classes to messages.
Look at this macro definition:
#define chain_msg_map (thechainclass) /
{/
IF (ThechainClass :: ProcessWindowMessage (HWND, UMSG, WPARAM, LPARAM, LRESULT)) /
Return True; /
}
Very simple, it only calls the processWindowMessage () function of the base class.
That is, the processWindowMessage () of the CDerived class contains two parts, part of the message processing function that calls processing WM_LButtondown, which is a member function of the class. The second part is to call the ProcessWindowMessage () function of the CBASE class, which is used to process the WM_DESTROY message.
In the package of the window function, we will know that CDERIVED will pass to the default window function for other messages.
Dead and Alt_MSG_MAP ()
If we want to derive a new window class on the CBase class. In addition to different processing for WM_RBUTTONDOWN, this class also wants CBASE to respond to WM_DESTROY messages different from the previous example. For example, I hope to prompt the window information.
How to deal with it? ATL provides a mechanism that is implemented by ALT_MSG_MAP (). It makes a class of message mappings to process multiple Windows window classes.
The following is a specific example:
// in Class CBase:
Begin_msg_map (CBASE)
Message_handler (WM_DESTROY, ONDESTROY1)
Alt_msg_map (100)
Message_handler (WM_DESTROY, ONDESTROY2)
END_MSG_MAP ()
Alt_msg_map () divides the message mapping into two parts. The message map of each part has an ID. The IDs of the message maps above are 0 and 100, respectively.
Analyze Alt_MSG_MAP ():
#define alt_msg_map (msgmaPID) /
Break; /
Case msgmapid:
Very simple, it ends the process of the previous MSGMapID and starts to enter another MSGMapID process.
Then, how do you connect the logical logic of the two classes of the processWindowMessage () function in the CDeriveD class.
// in class cderived:
Begin_MSG_MAP (CDerived)
CHAIN_MSG_MAP_ALT (CBASE, 100)
END_MSG_MAP ()
Here, use a chain_msg_map_alt () macro. Its specific definition is as follows:
#define chain_msg_map_alt (thechainclass, msgmapid) /
{/
IF (Thechainclass :: ProcessWindowMessage (Hwnd, UMSG, WPARAM, LPARAM, LRESULT, MSGMAPID) /
Return True; /
}
No reason is analyzed. Please refer to the analysis of Chain_MSG_MAP () macro.
