Have a weekend past, went to see the diving competition yesterday, the atmosphere at the scene is still good. Unfortunately, Tian Liang has not come, otherwise, light looks at the FANS of the audience is also a kind of enjoyment. At the end of nonsense, enter the topic, today did not say clearly before. The last mentioned message reflection, but there is no in-depth, this concept is such that many window controls send some messages to the parent window, such as the WM_COMMAND message and the WM_NOTIFY message, inform the parent window some events. Because it is sent to the parent window, the process function of the control window cannot capture these messages. However, we often want to handle these messages in the control window object so that the control class is more independent. In order to achieve this, both MFC and ATL provide a mechanism for message reflection, which is to let the parent window send them to the control window when receiving such messages, which is the message reflection. We have to implement the SKIN plug-in, but we need to receive these messages in the control window class, but we cannot rely on ATL or MFC reflection because we hope that the SKIN plug-in can be used by different host programs, rather than being limited to ATL and MFC. Other programs may have no messaging mechanism, or use different message reflection mechanisms. Therefore, we have implemented our own message reflex mechanism. The CREFLECTHOOK class is used to complete the message reflection, the constructor accepts the handle of the parent window as a parameter, and then calls SubClassWind to link the object instance to the window, which is similar to the implementation of the control. ProcessWindowMessage is a virtual function that can be confined to the bottom of the ATL window class, CREFLECTHOOK :: ProcessWindowMessage implements the reflection function, and send the received message back to the control window. But it is not simply returned, but is packaged into another WM_REFLECT message to avoid conflict with other messages. When a message is sent it will give the reflection control window, window controls with the following three macros unlock WM_REFLECT, and get the original message: LF_REFLECTED_NOTIFY_CODE_HANDLERLF_REFLECTED_COMMAND_CODE_HANDLERLF_REFLECTED_MESSAGE_HANDLER these macros meaning not much to say, the students are familiar with WTL it is easy to find the answer. Also worth mentioning the WM_GetReflector message, this custom message can be used to query the parent window to avoid the associated CreflectHook instance to avoid repeatedly installing the reflection hook, because CREFLECTHOOK :: ProcessWindowMessage returns the THIS pointer for this message. CWIDGETHOK :: INSTALL uses the WM_GetReflector message. It's worth talking about it, and finally tells how to write CWIDGETHOK inheritance (ie controls), which also directly affects the final effect. WTL defines a number of universal control packages, which can be simplified as a second template parameter of these classes can be a follow-up. Of course, if there is no corresponding packaging class, the default parameters can also be received. Because the ATL / WTL's infrastructure, the control class's writing and writing an ATL window class is very similar to the ATL / WTL message map macro, of course, these macros need to be manually entered, not Wizard like MFC. In addition, the control class can also select 4 initialization and cleaning functions defined by the CWIDGETHOK, refer to the SKIN technology implementation framework (5).
