MFC technical note 62: Message reflection for Windows controls

Document directory

• HTML tags and JavaScript tutorial

HTML tags and JavaScript tutorial

MFC technical note 62: Message reflection for Windows controls

Nbsp;
Next article: analyze and understand the notification message-wm_notify

Function storepage () {d = Document; t = D. selection? (D. selection. type! = 'None '? D. selection. createRange (). Text: '') :( D. getselection? D. getselection (): ''); void (keyit = Window. Open ('HTTP: // www.365key.com/storeit.aspx? T = '+ escape (D. title) + '& U =' + escape (D. location. href) + '& C =' + escape (t), 'keyit', 'scrollbars = No, width = 475, Height = 575, Left = 75, Top = 20, status = No, resizable = Yes '); keyit. focus ();}

MFC technical note 62: Message reflection for Windows controls

MFC technical note 62: Windows Control
Message reflection

Author: Microsoft programmer Source: msdn98 updated: 2006-3-16 read:
65

 

 

Technical Note 062: Windows Control
Message reflection

Tn062: Message reflection for Windows controls
Technical notes
Message reflection
, A new feature in mfc4.0. It also describes how to use
Message reflection
Create a simple reusable control guide.
This technical note describes message reflection, a new feature in MFC 4.0. It also contains ctions for creating a simple reusable control that uses Message reflection.
This article does not explain how ActiveX Controls (formerly known as Ole controls) are implemented.
Message reflection
. For more information, see ActiveX Controls: subclassing a Windows Control in Visual C ++ programmer's guide.
This technical note does not discuss message reflection as it applies to ActiveX Controls (formerly called Ole controls ). please see the articleactivex controls: subclassing a Windows Control in Visual C ++ programmer's guide.
What is
Message reflection
?
What Is Message reflection?
The window sends notification messages frequently to its parent window. For example, many controls send control color notification messages (wm_ctlcolor or a variant of it) to their parent windows to allow their parent windows to provide a brush for drawing the control background.
Windows controls frequently send notification messages to their parent windows. for instance, please controls send a control color notification message (wm_ctlcolor or one of its variants) to their parent to allow the parent to supply a brush for painting the background of the control.
In versions earlier than Windows and mfc4.0, the parent window is usually a dialog box that responds to and processes these messages. This means that the code for processing these messages must be implemented in the parent window class, and each class must process these messages. In the above case, each dialog box that requires a custom background control has to process the control color notification message. If a widget can process its own background color and can be reused, things will become much simpler.
In Windows and in MFC prior to version 4.0, the parent window, often a dialog box, is responsible for handling these messages. this means that the code for handling the message needs to be in the parent window's class and that it has to be duplicated in every class that needs to handle that message. in the case abve, every dialog box that wanted controls with custom backgrounds wowould have to handle the control color notification message. it wocould be much easier to reuse code if a control class cocould be written that wocould handle its own background color.
In MFC 4.0, the old message mechanism is still working-the parent window can process notification messages. In addition, MFC 4.0 provides a
Message reflection
The new mechanism makes repeated use much easier.
Message reflection
These notification messages can be processed by both the control and its parent window. In the preceding example, you can write a control class that can process the background color by using the sent wm_ctlcolor message, everything will no longer rely on its parent window. (Note that
Message reflection
It can only be implemented in MFC, not in windows. Therefore, the parent window must be derived from cwnd.
Message reflection
).
In MFC 4.0, the old mechanic still works-parent windows can handle notification messages. in addition, however, MFC 4.0 facilitates reuse by providing a feature called "Message reflection" that allows these notification messages to be handled in either the child control window or the parent window, or in both. in the control background color example, you can now write a control class that sets its own background color by handling the reflected wm_ctlcolor message-all without relying on the parent. (note that since Message reflection is implemented by MFC, not by windows, the parent window class must be derived from cwnd for Message reflection to work .)
The old version of MFC Implements similar functions by providing virtual functions for some messages. The most typical is self-drawn list boxes (wm_drawitem and so on ). Then the new
Message reflection
The mechanism is more generic and persistent.
Older versions of MFC did something similar to message reflection by providing virtual functions for a few messages, such as messages for owner-drawn list boxes (wm_drawitem, and so on ). the new message reflection mechanic is generalized and consistent.
The message mechanism is backward compatible with the code before mfc4.0.
Message reflection is backward compatible with code written for versions of MFC previous to 4.0.
If you provide a processing function for one or a specific range of messages in the parent window class of the control, for the same message, if you do not call the handler of the base class during your processing, it overwrites the reflected message processing. For example, if you try to process wm_ctlcolor in a dialog box class, your processing will overwrite any reflected message processing function.
If you have supplied a handler for a specific message, or for a range of messages, in your parent window's class, it will override reflected message handlers for the same message provided you don't call the base class handler function in your own handler. for example, if you handle wm_ctlcolor in your dialog box class, your handling will override any reflected message handlers.
If you provide a processing function for one or a series of specific wm_notify messages in the parent window, your processing function only works when these subcontrols send messages pass on_policy_reflect () the Macro will not process any reflected message. If true is returned for the processing, the message is also processed by the parent window. If the returned value is false, the parent window is not allowed to process the message. Note: The reflected message is processed before the notification message.
If, in your parent window class, you supply a handler for a specific wm_notify message or a range of wm_notify messages, your handler will be called only if the child control sending those messages does not have a reflected message handler through on_policy_reflect (). if you use on_policy_reflect_ex () in your message map, your message handler may or may not allow the parent window to handle the message. if the handler returns true, the message will be handled by the parent as well, while a call that returns false does not allow the parent to handle it. note that the reflected message is handled before the notification message.
When a wm_notify message is sent, the control gets the first chance to process it. If any other reflected message is sent, the parent window will have the first chance to process it, and the control will be able to receive the reflected message. To achieve this purpose, a processing function and an appropriate entry are required in the control-class message ing.
When a wm_policy message is sent, the control is offered the first chance to handle it. if any other reflected message is sent, the parent window has the first chance to handle it and the control will receive the reflected message. to do so, it will need a handler function and an appropriate entry in the control's class message map.
The message ing macro of a reflected message has a slight difference from the message ing macro of a common notification: it needs to add _ reflect in its regular name. For example, to process the wm_notify message in the parent window, you can use the macro on_notify in the message ing of the parent window class. To process reflection messages in the Child control class, you must use on_policy_reflect to respond to messages. In some cases, parameters are also different. Note: classwizard (Class Wizard) can usually add a message entry for you and provides a general framework for implementing functions with correct parameters.
The message-map macro for reflected messages is slightly different than for regular notifications: It has _ reflect appended to its usual name. for instance, to handle a wm_policy message in the parent, you use the macro on_policy in the parent's message map. to handle the reflected message in the Child control, use the on_policy_reflect macro in the Child control's message map. in some cases, the parameters are different, as well. note that classwizard can be usually add the message-map entries for you and provide skeleton function implementations with correct parameters.
See tn061: on_notify and wm_notify in the new wm_notify message
See tn061: on_policy and wm_policy messages for information on the new wm_policy message.
Message ing entry and processing function prototype for reflected messages
Message-map entries and handler function prototypes for reflected messages
To process reflected control notification messages, use the message ing macro and function prototype listed in the following table.
To handle a reflected control notification message, use the message-map macros and function prototypes listed in the table below.
Classwizard can usually add a message ing entry for you and provide you with a skeleton for implementing functions. See
Defining a message handler for a reflected message in the Visual C ++ programmer's Guide to obtain information about how to define processing functions for reflected messages.
Classwizard can usually add these message-map entries for you and provide skeleton function implementations. seedefining a message handler for a reflected message in the Visual C ++ programmer's guide for information about how to define handlers for reflected messages.
To convert the message name to the macro name to be reflected, add on _ before the message name, and then add
_ Reflect. For example, the corresponding wm_ctlcolor is changed to on_wm_ctlcolor_reflect.
To convert from the message name to the reflected macro name, prepend on _ and append _ reflect. for example, wm_ctlcolor becomes on_wm_ctlcolor_reflect. (To see which messages can be reflected, do the opposite conversion on the macro entries in the table below .)
The above rules are generally used, but there are three exceptions:
The three exceptions to the rule above are as follows:
The macro used for wm_command notification is on_control_reflect;
The macro used for wm_notify notification is on_policy_reflect;
The macro used for on_update_command_ui notifications is on_update_command_ui_reflect.
The macro for wm_command configurications is on_control_reflect.
The macro for wm_notify reflections is on_policy_reflect.
The macro for on_update_command_ui reflections ctions is on_update_command_ui_reflect.
In the preceding special circumstances, you must specify the name of the processing member function. In other cases, you must use the Standard handler name.
In each of the above special cases, you must specify the name of the handler member function. I
N the other cases, you must use the standard name for your handler function.
The meanings of function parameters and returned values are listed under the function name or have been written in advance. For example, ctlcolor is represented as onctlcolor in the document. The number of parameters required by several reflected message processing functions is less than that required by the corresponding function in its parent window. See the formal parameters in the following table.
The meanings of the parameters and return values of the functions are supported ented under either the function name or the function name with on prepended. for instance, ctlcolor is already ented in onctlcolor. several reflected message handlers need fewer parameters than the similar handlers in a parent window. just match the names in the table below with the names of the formal parameters in the documentation.
Ing macro entry function prototype
On_control_reflect (wnotifycode, memberfxn) afx_msg void memberfxn ();
On_policy_reflect (wnotifycode, memberfxn) afx_msg void memberfxn (nmhdr * ppolicystruct, lresult * result );
On_update_command_ui_reflect (memberfxn) afx_msg void memberfxn (ccmdui * pcmdui );
On_wm_ctlcolor_reflect () afx_msg hbrush ctlcolor (CDC * PDC, uint nctlcolor );
On_wm_drawitem_reflect () afx_msg void drawitem (lpdrawitemstruct );
On_wm_measureitem_reflect () afx_msg void measureitem (lpmeasureitemstruct );
On_wm_deleteitem_reflect () afx_msg void deleteitem (lpdeleteitemstruct );
On_wm_compareitem_reflect () afx_msg int compareitem (lpcompareitemstruct );
On_wm_chartoitem_reflect () afx_msg int chartoitem (uint nkey, uint nindex );
On_wm_vkeytoitem_reflect () afx_msg int vkeytoitem (uint nkey, uint nindex );
On_wm_hscroll_reflect () afx_msg void hscroll (uint nsbcode, uint NPOs );
On_wm_vscroll_reflect () afx_msg void vscroll (uint nsbcode, uint NPOs );
On_wm_parentpolicy_reflect () afx_msg void parentnotify (uint message, lparam );
On_policy_reflect and on_control_reflect have several variants to allow multiple objects such as controls and their parent window to process a given message.
The on_policy_reflect and on_control_reflect macros have variations that allow more than one object (such as the control and its parent) to handle a given message.
Ing macro entry function prototype
On_policy_reflect_ex (wnotifycode, memberfxn) afx_msg bool memberfxn (nmhdr * ppolicystruct, lresult * result );
On_control_reflect_ex (wnotifycode, memberfxn) afx_msg bool memberfxn ();
Process reflected messages: Example of reusable controls
Handling reflected messages: An example of a reusable Control
This simple example creates a reusable control called cyellowedit. This control has almost the same functions as a general editing control. The difference is that it displays black characters in the yellow background. Of course, you can easily add some member functions to display different colors.
This simple example creates a reusable control called cyellowedit. the control works the same as a regular edit control variable t that it displays black text on a yellow background. it wocould be easy to add member functions that wocould allow the cyellowedit control to display different colors.
1. follow these steps:
To try this example, do the following steps:
In the Add a dialog box for an existing application, see dialog editor in the Visual C ++ user's guide.
You must have an existing application to develop reusable controls. If you do not have any applications available, use Appwizard to create a dialog box-based application.
Create a new dialog box in an existing application. For more information seedialog editor in the Visual C ++ user's guide.
You must have an application in which to develop the reusable control. If you don't have an existing application to use, create a dialog-based application using Appwizard.
After VC ++ loads your application, you can use classwizard to create a new cyellowedit Class Based on the cedit class. Cancel the "add to component Gallery" option.
With your project loaded into visual C ++, use classwizard to create a new class called cyellowedit Based on cedit. Leave the "add to component Gallery" box checked.
Add three member variables to the cyellowedit class. The first two are colorref variables to record the text and background color. The third variable is a brush class cbrush variable used to draw the background. The brush variable allows you to create it only once, and then you only need to reference it until the cyellowedit control is destroyed.
Add three member variables to your cyellowedit class. the first two will be colorref variables to hold the text color and the background color. the third will be a cbrush object which will hold the brush for painting the background. the cbrush object allows you to create the brush once, merely referencing it after that, and to destroy the brush automatically when the cyellowedit control is destroyed.
Initialize these member variables in the constructor:
Initialize the member variables by writing the constructor as follows:
Cyellowedit: cyellowedit ()
{
M_clrtext = RGB (0, 0, 0 );
M_clrbkgnd = RGB (255,255, 0 );
M_brbkgnd.createsolidbrush (m_clrbkgnd );
}
Use classwizard to add a processing function for the wm_ctlcolor reflection message of your cyellowedit class. Note: The equal sign before the message name in the message list that you can process indicates that the message is a message that can be reflected. This is described in defining a message handler for a reflected message in the Visual C ++ programmer's guide. Classwizard will add the following message ing macro and the corresponding function skeleton for you:
Using classwizard, add a handler for the reflected wm_ctlcolor message to your cyellowedit class. note that the equal sign in front of the message name in the list of messages you can handle indicates that the message is reflected. this is described indefining a message handler for a reflected message in the Visual C ++ programmer's guide.
Classwizard adds the following message-map macro and skeleton function for you:
On_wm_ctlcolor_reflect ()
// Note: Other code will be in ....
Hbrush cyellowedit: ctlcolor (CDC * PDC, uint nctlcolor)
{
// Todo: change any attributes of the DC here
// Todo: return a non-null brush if
// Parent's handler shocould not be called
Return NULL;
}
Use the following code to replace the main body of the function. The program code is simple, that is, specify the text color, text background color, and the background color of the rest of the control.
Replace the body of the function with the following code. The Code specifies the text color, the text background color, and the background color for rest of the control.
PDC-> settextcolor (m_clrtext); // text
PDC-> setbkcolor (m_clrbkgnd); // text bkgnd
Return m_brbkgnd; // CTL bkgnd
Create an edit control in the dialog box, press the next control key, and double-click Edit Control to associate it with a member variable. Complete the variable name when adding a member variable to the dialog box, and select "cyellowedit" in the "control" as your variable prototype. Do not forget to set the tab order in your dialog box. In addition, do not forget to add the cyellowedit Class header file in the header file of your dialog box.
Create an edit control in your dialog box, then attach it to a member variable by double-clicking the edit control while holding a control key down. in the Add member variable dialog box, finish the variable name and choose "control" for the category, then "cyellowedit" for the variable type. don't forget to set the tab order in the dialog box. also, be sure to include the header file for the cyellowedit control in your dialog box's header file.
Compile and run your program. The editing control displays a yellow background.
Build and run your application. The edit control will have a yellow background.
Now you can use component gallery to add your cyellowedit control class to other projects.

 
Http://www.itnewscn.com/VC/MFC/0405005.htm