On_command_range multiple buttons to respond to a function solution _c language

This article describes a solution for on_command_range multiple buttons to respond to a function.

Developers need to pay attention to the custom message response function in the declaration process, must pay attention to the form of parameters, a slight negligence will lead to false errors, specifically to On_command_range as an example.

1. Declare a message response function: Add a function to the project to be added afx_msg void Onbuttonport ();

2. Message mapping:

Begin_message_map (Cxxxdlg, CDialog)
//{{afx_msg_map (Cxxxdlg
) On_wm_syscommand () On_wm_paint () On_wm_timer ()
//}}afx_msg_map

//There are a number of BUTTON between Idc_button_port_1 and Idc_button_start_all here, and ID is continuous
on_ Command_range (idc_button_port_1, Idc_button_start_all, Onbuttonport)
on_wm_devicechange ()
END_MESSAGE_ MAP ()

3. Realization of mapping function: Implement your own response function void Cxxxdlg::onbuttonport ()

Note: This code debug Ok,relase exception, not directly referenced, and listen to the following decomposition:

Debug through, but the release but directly collapsed, wrote so many years of code is really the first time encountered this situation, why On_command_range Debug Normal, release not normal?

MSDN First:

 Use this macro to map a contiguous range ' command IDs to a single message handler fun
Ction.
On_command_range (ID1, Id2, memberfxn) Parameters id1 command ID at the beginning of a contiguous RANGE of command IDs.
ID2 command ID at the end of a contiguous range of Command IDs.
MEMBERFXN the name of the Message-handler function to which the commands are mapped.
Remarks the range of IDs starts with ID1 and ends with Id2. Use On_command_range to map a RANGE of COMMAND IDs to one member function. Use On_command to map a single COMMAND to a member function. Only one Message-map entry can match a given command ID. That's, you can ' t map a command to more than one handler.
For the information on mapping message ranges, the handlers for Message-map ranges.

The There is no automatic support to message map ranges, so you must place the macro yourself. 

MSDN also did not specifically note what to pay attention to, I think I use is also very normal, so I searched the Internet again a convention, there is a very professional explanation of the reasons, the specific URL is: http://yiyunscu.blog.163.com/blog/static/ 3626332020099802057982/

The following are reproduced content:

The user is defined as follows:

afx_msg void Oncommandmy (WPARAM WPARAM, LPARAM LPARAM);

Declares a function declaration that applies only to on_command messages, while the On_command_range function affirms that it is recommended in MSDN:
Oncommandmy (UINT NID);
Via switch (NID) case * *: message response for different menus.
Nid is the ID number of the incoming message in the menu, and oddly enough, in the debug version, the previous statement was completely normal, checking MSDN for possible reasons:

 Handler functions for a single commands normally take no parameters. With the exception of update handler functions, handler functions for Message-map ranges, require, extra, parameter, of type UINT. This is the parameter-parameter. The extra parameter accommodates the extra command ID needed to specify which command the user actually chose.

A single command message response function can be without parameters, but for multiple command messages such as On_command_range, the first parameter in the function argument list needs to be defined as UINT NID, indicating the ID number of the command. As MSDN understands it, On_command_range can also define two parameters in a message response function like On_command, such as afx_msg void Oncommandmy (WPARAM WPARAM, LPARAM LPARAM); In the debug and release, the compilation will not be a problem, running in debug will not be a problem, but in the release under the memory error, so you can take more than one parameter feeling can only be able to work under debug, under release will not fail.
Check the relevant information and use VC to view the corresponding assembly code found that the function call and return when the stack operation imbalance caused the release version of the problem of memory error, on_command_range in the MFC default message response function, the parameter is only one, such as:

#define ON_COMMAND_RANGE (ID, idlast, memberfxn) \
 {wm_command, Cn_command, (word) ID, (word) idlast, AFXSIG_VW, \ (
 afx_pmsg) (void (Afx_msg_call CCmdTarget::*) (UINT) &memberfxn},
 //On_command_range (ID, idlast, onfoo) Is the same as
 //  on_control_range (0, ID, idlast, onfoo)

During the function call, the incoming parameters are pushed to the stack, because MFC has only one default incoming parameter, so when the call to Oncommandmy there is a system incoming message parameters for the stack operation. When the function returns, the stack operation should be done and the stack will be balanced when the call is complete, otherwise a possible memory error may occur. No memory error occurred on debug because the compiler added the following assembly code at the return code when the call to the ONCOMMANDMY function returned:

Pop edi pop
esi pop
ebx
add ESP, 48h
CMP EBP, esp call
__chkesp (0041e680)
mov esp, ebp
pop EB P
ret 8 (two parameters out of stack)

The purpose of this assembler code is to check that the stack is consistent when the function returns, and if it is inconsistent, force the stack operation, because in this call process, the message parameters of the incoming oncommandmy are only one (only the declaration is two, actually only one parameter is passed in), Therefore, there is a stack inconsistency, but forcing the flat stack can avoid the resulting errors.
In release version, there is no check stack operation,
Just a few simple words in the following assembly code to complete the stack operation:

mov esp, ebp
pop ebp
ret 82 parameters out stack)

It can be seen that the release under the stack operation imbalance, that is, the number of stack is less than the number of stacks, resulting in the stack area address errors, when other functions two times to the stack area address access is very likely to occur memory errors.
Therefore, usually write the program in debug under the height of the completion, it is best to look at the release, because sometimes, debug the function parameters of the check is not so strict, and in the stack operation, debug can help us solve a lot of hidden problems, But it's not going to happen under release. Additionally, in a custom message response function, Debug and release do not detect consistency between the response function's parameter list and the MFC default parameter list, potentially hiding significant memory errors, resulting in the possibility of a crash of the final software running under release.

Finally understand, the original is On_command_range can only take one parameter, with two or no will be abnormal so redefine:

afx_msg void Onbuttonport (UINT nID);

And this NID is the button ID value you clicked, no more trouble code.

CWnd *pwnd = GetFocus ();
int nportid = Pwnd->getdlgctrlid ();

Problem solved!

Additional:

1, On_command (id_view_customize, onviewcustomize) ==>void cmainframe::onviewcustomize () or void CMainFrame::O Nviewcustomize (WPARAM WPARAM, LPARAM LPARAM);

2, On_registered_message (Afx_wm_resettoolbar, Ontoolbarreset) ==>afx_msg lresult Cmainframe::ontoolbarreset ( WPARAM/*wp*/,lparam);

3, On_command_range (id_shortcut_1, Id_shortcut_5, onoutlookbarshortcut) ==>void cmainframe::onoutlookbarshortcut (UINT ID);

4, ON_UPDATE_COMMAND_UI (Id_view_captionbar, Onupdateviewcaptionbar) ==>void Cmainframe::onupdateviewcaptionbar ( ccmdui* pCmdUI);