| Date: | February 24, 2005 / year-entry #46 |
| Tags: | code;modality |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20050224-00/?p=36373 |
| Comments: | 10 |
| Summary: | Here is the very simple fix for the buggy program we presented last time. void OnChar(HWND hwnd, TCHAR ch, int cRepeat) { switch (ch) { case ' ': MessageBox(hwnd, TEXT("Message"), TEXT("Title"), MB_OK); if (!IsWindow(hwnd)) MessageBeep(-1); break; } } We have fixed the problem by passing the correct owner window for the modal UI. Since MessageBox... |
Here is the very simple fix for the buggy program we presented last time.
void OnChar(HWND hwnd, TCHAR ch, int cRepeat)
{
switch (ch) {
case ' ':
MessageBox(hwnd, TEXT("Message"), TEXT("Title"), MB_OK);
if (!IsWindow(hwnd)) MessageBeep(-1);
break;
}
}
We have fixed the problem by passing the correct owner window
for the modal UI. Since
This is why all the shell functions that can potentially display
UI accept a window handle as one of its parameters.
They need to know which window to use as the owner for any
necessary UI dialogs. If you call such functions from a thread
that is hosting UI, you must pass the handle to the window you
want the shell to use as the UI owner. If you pass NULL
(or worse, If you are displaying a modal dialog from another modal dialog, it is important to pass the correct window as the owner for the second dialog. Specifically, you need to pass the modal dialog initiating the sub-dialog and not the original frame window. Here's a stack diagram illustrating:
MainWindow
DialogBox(hwndOwner = main window) [dialog 1]
... dialog manager ...
DlgProc
DialogBox(hwndOwner = dialog 1) [dialog 2]
If you mess up and pass the main window handle when creating the second modal dialog, you will find yourself back in a situation analogous to what we had last time: The user can dismiss the first dialog while the second dialog is up, leaving its stack frames orphaned. |
Comments (10)
Comments are closed. |
I have a windowless ActiveX control and it sometimes needs to pop a dialog box. If the container is IE or WebBrowser, IObjectWithSite gives me the container’s IUnknown and from there I can get the IWebBrowser2.HWND property. Otherwise I punt back to NULL, for example if called from a WScript.exe script. Is there a generic way to get any container’s HWND?
WTL is using GetActiveWindow as parent by default. Will that work in all cases? What will happen for example if a tooltip pops up – will that be the active window?
Tooltips never get activation. The Active Window is the one which is … erm… active – not the one on the top of the Z-order.
Dave: ActiveX controls can use their host’s IOleWindow interface to get its HWND.
I’m sure these series are great for those that can understand them, but how about a little lighter fare to break this one up? Something simple even I can understand like "Why does Windows do such and such?" And then tell us about the good old days and how they transitioned to the even better later days.
Funny, just yesterday, I came across a problem with HtmlHelp in a debug MFC build of my project.
If I clicked on the dialog, sometimes, the program would assert in _AfxHandleActivate, after the WM_ACTIVATE was called.
It seems that despite setting the parent window correctly, because HTML help is on another thread, the window pointed to as being deactivated will not necessarily exist, as it was on another thread.
And we all know how much MFC likes windows from multiple threads ;)
Apparently the solution is to initialize HTML Help as single threaded, and pass it messages (yuck).
Ivo> Yeah, the default of GetActiveWindow() has bitten me a couple times in the past. Now I’m in the paranoid habit of passing an HWND to every DoModal(), luckily most of the time "*this" is sufficient so it’s not a hassle.
Respect the modality of a window.
Otherwise you end up creating the impossible.