Chhandle_dlgmsg (Windows core programming)

After reading "windows programming", I started to read "Windows core programming".

The results showed that the code of Jeffery was very profound in the first case. At first glance, it seems that windows. H is not included.

Check the contained header file and find that cmnhdr. h already contains windows. h. The code in cmnhdr. H is even more scary. I don't know what to think if I haven't explained it. Later, I learned that the book had a special introduction to the environment, and basically explained cmnhdr. h.

 

Cmnhdr. h contains many things of Daniel. When we see the macro chhandle_dlgmsg, we know that there is such a message shunt. Later, I searched for information and found many things I did not know before. I will not introduce the specific message shunt. I just want to explain the motivation of reading chhandle_dlgmsg repeatedly. The description in this document is very short. It just means that handle_msg cannot return true or false for the process of processing the message dialog box to tell whether we have processed the message in the dialog box process. Why cannot handle_msg be returned correctly?

 

The reason is that handle_msg is only for simple conversion of handle _ # message. # Message refers to the connection between handle and a specific message, and is a macro definition of the message (such as wm_initdialog instead of 0x0110 ). For example:

Handle _ # wm_initdialog to get handle_wm_initdialog, but you cannot write the specific number of wm_initdialog into it.

 

Handle_msg macro is defined as follows:

 

# Define handle_msg (hwnd, message, FN )/
Case (Message): Return handle _ # message (hwnd), (wparam), (lparam), (FN ))

 

We can see that only the case and return statements are added. Therefore, handle_msg only considers that the form is correct, but cannot handle the return values of all message processing. The return of handle_msg depends entirely on handle _ # message macro.

 

If the message of handle _ # message is wm_initdialog, handle _ # message is handle_wm_initidalog.

 

Handle_wm_initdialog macro is defined as follows:

 

# Define handle_wm_initdialog (hwnd, wparam, lparam, FN )/
(Lresult) (DWORD) (uint) (bool) (FN) (hwnd), (hwnd) (wparam), lparam)

 

You can see that if handle_msg (hwnd, wm_initdialog, dlg_initdialog) is used in the message dialog box, there is no problem. Yes, I only said that there is no problem with wm_initdialog. If there are so many messages in windows, other messages will be very problematic. Check the wm_command message!

 

Handle_wm_command macro is defined as follows:

 

# Define handle_wm_command (hwnd, wparam, lparam, FN )/
(FN) (hwnd), (INT) (loword (wparam), (hwnd) (lparam), (uint) hiword (wparam), 0l)

 

It can be seen that handle_wm_command has no return value at all, because the FN form does not specify the return value. No return value. Why is handle_msg returned?

This is the problem of handle_msg. handle_wm_command is designed to implement the process between case wm_command and return true. Handle_msg is a simple encapsulation, so this is the problem of handle_msg.

 

We should use the setdlgmsgresult macro to correctly return the message processing process in the dialog box. This is the macro used by Daniel chhandle_dlgmsg. The chhandle_dlgmsg encapsulates setdlgmsgresult.

 

This is the macro definition of Daniel's chhandle_dlgmsg:

 

# Define chhandle_dlgmsg (hwnd, message, FN )/
Case (Message): Return (setdlgmsgresult (hwnd, umsg ,/
Handle _ # message (hwnd), (wparam), (lparam), (FN ))))

 

This is the macro definition of setdlgmsgresult:

 

# Define setdlgmsgresult (hwnd, MSG, result )((/
(MSG) = wm_ctlcolormsgbox |/
(MSG) = wm_ctlcoloredit |/
(MSG) = wm_ctlcolorlistbox |/
(MSG) = wm_ctlcolorbtn |/
(MSG) = wm_ctlcolordlg |/
(MSG) = wm_ctlcolorscrollbar |/
(MSG) = wm_ctlcolorstatic |/
(MSG) = wm_compareitem |/
(MSG) = wm_vkeytoitem |/
(MSG) = wm_chartoitem |/
(MSG) = wm_querydragicon |/
(MSG) = wm_initdialog/
)? (Bool) (result): (setwindowlongptr (hwnd), dwlp_msgresult, (lparam) (lresult) (result), true ))

 

In chhandle_dlgmsg, the return value is returned even if setdlgmsgresult is returned. So what value does setdlgmsgresult return?

Let's see if the message is

(MSG) = wm_ctlcolormsgbox |/
(MSG) = wm_ctlcoloredit |/
(MSG) = wm_ctlcolorlistbox |/
(MSG) = wm_ctlcolorbtn |/
(MSG) = wm_ctlcolordlg |/
(MSG) = wm_ctlcolorscrollbar |/
(MSG) = wm_ctlcolorstatic |/
(MSG) = wm_compareitem |/
(MSG) = wm_vkeytoitem |/
(MSG) = wm_chartoitem |/
(MSG) = wm_querydragicon |/
(MSG) = wm_initdialog/
The return value is the return value of the function we wrote. The result is replaced with the message processing function FN in chhandle_dlgmsg. If the message is not contained in the message, run setwindowlongptr (later) and return true (based on the comma operator ). Note that the message processing function result (in fact, FN) is called when setwindowlongptr is executed ).

 

But why? These wm_ctlcolormsgbox wm_ctlcoloredit... Is there anything special? The returned values of these messages are known and have their own meanings. For these messages, you only need to return the return values processed by their functions to make the program run normally. However, it is hard to say that the message wm_command is probably a notification message of a control. A value may be zero or not zero, so it cannot be processed like wm_ctlcolormsgbox, in most cases, true indicates that the user processes the message. If false or 0 indicates that the user does not process the message, the parent message processing process of the dialog box is processed by default. In this case, if a message processed by wm_command needs to return 0, what should we do? In this case, true is returned first, and setwindowlongptr is used to set the returned value. If true is returned, it indicates to the parent window that you have processed it, but the returned value is replaced with the value of setwindowlongptr, in this way, you can work normally. That's it!

 

In fact, the root cause of this bypass is:

 

The dialog box message process in Windows is handled in this way.

Lresult callback defdlgproc (hwnd hdlg, uint umsg, wparam, lparam)
{
Dlgproc dp = (dlgproc) getwindowlongptr (hdlg, dwlp_dlgproc );
Setwindowlongptr (hdlg, dwlp_msgresult, 0 );
Int_ptr fresult = dp (hdlg, umsg, wparam, lparam );
If (fresult) return getwindowlongptr (hdlg, dwlp_msgresult );
Else... do the default thing...
}

 

 

The above code is reproduced as the content of a csdn friend. I will explain it a bit:
This is because the real message processing process in the dialog box is like this. The return value indicates whether the message is processed in the dialog box process (the Dialog Box Process and the dialog box process should be distinguished (..., dlg_msgresult) sets the return value of the dialog box, because getwindowlongptr is used in the dialog box to obtain this value and properly handle it.

 

Continue to work!