Dialog manager in the fourth chapter: the dialog message loop

The dialog message loop is actually not complicated. Its core implementation code is the following lines of code:

while (
 &&GetMessage(&msg, NULL, 0, 0, 0)) {if (!IsDialogMessage(hdlg, &msg)) {TranslateMessage(&msg);DispatchMessage(&msg);}}

However, let's start from the beginning.The story happens when DialogBoxIndirectParam is called. You should remember that we explained before that the system will convert all calls to DialogBoxXX into calls to DialogBoxIndirectParam. The code is as follows:

INT_PTR WINAPI DialogBoxIndirectParam(HINSTANCE hinst,LPCDLGTEMPLATE lpTemplate, HWND hwndParent,DLGPROC lpDlgProc, LPARAM lParam){/** App hack! Some people pass GetDesktopWindow()* as the owner instead of NULL. Fix them so the* desktop doesn't get disabled!*/if (hwndParent == GetDesktopWindow())hwndParent = NULL;

Yes, we did an App Hack in the code.In the previous article, we discussed the issue of passing GetDesktopWindow() as the parent window.A lot of developers made this mistake and we had to build this App Hack into the core OS code.If we don't do this, hundreds of upper layer applications will need to be changed.

Since only top-level windows can be the window owner, we have to start from hwndParent (possibly a child window) and work our way up the window hierarchy until we find a top-level window.

 if (hwndParent)hwndParent = GetAncestor(hwndParent, GA_ROOT);

After completing the second App Hack, we started to create our dialog:

 HWND hdlg = CreateDialogIndirectParam(hinst,lpTemplate, hwndParent, lpDlgProc,lParam);

Note: As before, I'll ignore error checking and various dialog boxes, as it just distracts from the point of this entry.
Because modal dialogs disable their parent window, implement it here:

 BOOL fWasEnabled = EnableWindow(hwndParent, FALSE);

Then we enter the dialog modal message loop:

 MSG msg;while (
 &&GetMessage(&msg, NULL, 0, 0)) {if (!IsDialogMessage(hdlg, &msg)) {TranslateMessage(&msg);DispatchMessage(&msg);}}

According to the convention of window exit messages, we redelive any exit message we might receive so that it can be seen by the next outer modal loop.

 if (msg.message == WM_QUIT) {PostQuitMessage((int)msg.wParam);}

(Astute readers may have noticed look, there is an uninitialized variable error in the code above: if EndDialog is called during WM_INITDIALOG processing, msg.message is never set. For illustration purposes, I decidedIgnore this error.)

At this point, our dialog has done its job, and we need to clean it up.Remember to enable the owner before destroying the owned dialog.

if (fWasEnabled)EnableWindow(hwndParent, TRUE);DestroyWindow(hdlg);

Finally, return the result:

 return ;}

Congratulations, you are now a dialog expert.Tomorrow, we'll see how to make the most of the expertise learned today.

Exercise: Find a way to sneak through the App Hack about the parent window in the two layers of code above to end up with a dialog whose owner is the desktop, and explain the dire consequences of this situation.

Summary

Okay, dialog expert, you see it: there is nothing mysterious under the code, there is cause and effect.
This world is still materialistic.

Last

Raymond Chen's "The Old New Thing" is one of my favorite blogs. It contains a lot of small knowledge about Windows, which is really helpful for the majority of Windows platform developers.
This article is from: "The dialog manager, part 4: The dialog loop"