Modality, part 9: Setting the correct owner for modal UI, practical exam

Date:	January 21, 2011 / year-entry #15
Tags:	code
Orig Link:	https://blogs.msdn.microsoft.com/oldnewthing/20110121-00/?p=11703
Comments:	22
Summary:	Here's a question that came from a customer. You can answer it yourself based on what you know about modal UI. (If you're kind of rusty on the topic, you can catch up here.) I've left in some irrelevant details just to make things interesting. Our program launches a helper program to display an Aero...

Here's a question that came from a customer. You can answer it yourself based on what you know about modal UI. (If you're kind of rusty on the topic, you can catch up here.) I've left in some irrelevant details just to make things interesting.

Our program launches a helper program to display an Aero Wizard to guide the user through submitting a service request.
theWiz.DoModal(hwndMainFrame);
There are no EnableWindow calls leading up to or returning from this call. the DoModal handles things nicely.

When the user clicks "Cancel" to cancel the service request, we use a TaskDialog so we can get the new look for our confirmation message box. The task dialog setup goes like this:
TASKDIALOGCONFIG config = { 0 };
config.cbSize = sizeof(config);
config.hwndParent = hwndMainFrame;
When the user clicks "Yes" to cancel, then another window instead of our frame becomes active.

On a hunch, I replaced the task dialog with a Win32 message box
MessageBox(hwndMainFrame, ...);
and bingo, we get the correct behavior. When our wizard exits, the main frame receives focus.

I believe that the "automatic" modal behavior that comes with DoModal() that takes care of disabling and reenabling the main frame is somehow getting short-circuited by using TaskDialog from inside our PSM_QUERYCANCEL message handler.

Right now, we've switched to MessageBox, but we would much prefer to use the task dialog.

Although it's not common, it is legal to have a window's parent or owner belongs to another thread or process. But it definitely makes things a bit more tricky to manage because it attaches the input queues of the two threads, and you now have two threads coöperating to manage a single window hierarchy.

Is the cross-process window hierarchy a contributing factor to the problem, or is it just a red herring?

Comments (22)

Nick says:

January 21, 2011 at 7:30 am

Why TaskDialogIndirect? And also where is the hInst for the TASKDIALOGCONFIG…
Pierre B. says:

January 21, 2011 at 7:53 am

From what I understand of the description of the problem, I think the TaskDialog should have used the Aero Wizard as its parent. This is assuming the cancel handling is done in the Wizard, prior to closing it. (The description of the workflow strongly implies that the confirmation is done before closing the wizard.)

I don't understand why MessageBox() works properly. Maybe it automatically detects that the parent is disabled and search for its active child?
doug.kavendek says:

January 21, 2011 at 7:55 am

I'm assuming that the call to the wizard's DoModal() with hwndMainFrame as a parameter is setting hwndMainFrame as the owner of the modal wizard (if that's not the case, then never mind this whole thing). The TaskDialog is setting hwndMainFrame as its parent. This means that there's two different dialogs that have the same owner, unless I'm getting myself confused by the differences between parent and owner. When the TaskDialog closes, it may re-enable and switch back to its owner, which is supposed to still be disabled and waiting on the wizard. That seems like it's guaranteed to lead to strange behavior.
Joshua says:

January 21, 2011 at 8:08 am

I have done cross-process owner/owned windows. It does work from native code, but managed code seemt to not like it.

I'm guessing that corss-process is a red herring here.
Adrian says:

January 21, 2011 at 8:57 am

I, too, would like clarification on whether the task dialog is shown prior to dismissing the wizard. If so, then the task dialog's parent should be the wizard, not the original program. Then the task dialog should return activation to the wizard which would in turn return it to the main window.

But I'm not sure why the message box works when the task dialog doesn't.
SMW says:

January 21, 2011 at 9:33 am

What's with the umlaut on the second 'o' in 'cooperating' (last sentence of second-to-last paragraph)? Is that a hint of some sort? :-)

[That's not an umlaut; it's a diaeresis. Coöperate is even called out by Wikipedia as an example. -Raymond]
Nawak says:

January 21, 2011 at 9:50 am

@SMW

Raymond is just trying to set a new trend, that's second time he writes cooperates this way this week…

Well of course if this entry is several years old as many are, then it's just a coincidence both mistakes happen the same week!

Or maybe Raymond is using his psychic powers to also write his comments several years before the story is published.

Or maybe we are ignorant youngins and Raymond is fan of this blog: http://thedutras.blogspot.com/
Nawak says:

January 21, 2011 at 9:53 am

Well… Raymond has answered in the time it took me to write the post, that's what I get for being slow :)

Now I'm slow AND an ignorant youngin…
SMW says:

January 21, 2011 at 10:39 am

The Wikipedia entry also states that its use is uncommon in English, stating that it is optional. I also don't read The New Yorker or the MIT Technology Review. And since I have a German background and took German language classes way back in high school I naturally think it's an umlaut. But then in English that would have been written differently.

[When I was a kid, we were taught to spell with the diaeresis and to put the apostrophe in Hallowe'en. Now get off my lawn. -Raymond]
Skyborne says:

January 21, 2011 at 10:59 am

that's second time he writes coöperates this way this week…

FTFY ;-)

Regarding the actual question, in my own code, it would most likely be that I forgot to pass config along to code that was expecting it, and MessageBox would work because it didn't need the config.
David Walker says:

January 21, 2011 at 12:03 pm

Raymond may be channeling the New Yorker magazine which sticks to the diaresis on cooperate and coordinate, even though most magazines and newspapers have dropped the use. I didn't think the English language had more than twenty-six letters, with no diacritical marks or accents — that's what I learned in elementary school. But there's amoeba, and diarrhoea, where oe is combined into one letter in older writings.
ChrisW says:

January 21, 2011 at 1:34 pm

Another process has the active Window and wants to give it away to another window?

I think calling AllowSetForegroundWindow should do the trick.

Maybe MessageBox handles this case to be backwards compatible to applications that don't know about the above.
PhilW says:

January 21, 2011 at 3:38 pm

Mmmm. I'm reading this in a tabbed IE frame. There are three tabs and four IE processes running, making me wonder if this is a case of a window's parent or owner belonging to another process.
DerekYu says:

January 21, 2011 at 5:59 pm

The correct modal UI is none.
Paul M. Parks says:

January 21, 2011 at 12:31 pm

Totally unrelated, but I just went to a search engine to try to find one of your articles for a co-worker. I didn't narrow to search to "blogs.msdn.com", however. The first hit in the results was an article on my *own* web site that happens to mention *another* article of yours. I think I'm going to mention you in all of my articles now. ;)
kinokijuf says:

January 21, 2011 at 9:20 pm

@Paul M. Parks: What post?
rs says:

January 21, 2011 at 9:43 pm

My guess: The TaskDialog is trying to set an owner window which is still disabled by the wizard. Maybe TaskDialog skips the EnableWindow/SetFocus calls for such a window while MessageBox doesn't.
Neil says:

January 22, 2011 at 3:11 am

Please can we learn to co-operate with Raymond? Thanks.

I remember a bug in Windows 3.1 where the last active popup didn't get updated for a background window with a nested dialog. In particular we used an app framework whose default print preview was in a popup and you could trigger the bug by switching away from the app while the print progress dialog (which closed automatically when it had finished printing) was active. In Windows 95 the bug was alleviated by setting the last active popup to NULL, and the bug was completely fixed in at least Windows 2000 (it may have been fixed in prior Windows NT versions but I didn't test it there.)
Anonymous Coward says:

January 22, 2011 at 3:53 am

Cross-process is a red herring; the wrong parent was used.

DerekYu: while I agree in principle, how would you have solved the problem at hand without a modal confirmation message?
Chris Becke says:

January 23, 2011 at 11:19 pm

As presented, this problem makes no sense. MessageBox and TaskDialog both implement a a modal popup. With the same parent window being specified, and with both being called from the PSM_QUERYCANCEL message the behavior of the application should be the same. Unless TaskDialog and MessageBox have internal differences in how they implement their modality. Cross process is also a red herring as, again, both examples are doing the same cross process things the same way. Which means there is some undisclosed piece of information that makes one of the scenarios not modal, or it was actually the Butler, in the pantry, with the serving fork.
when irrelevant details become more interesting than the original exercise says:

January 24, 2011 at 3:21 pm

Yeah, I think the "irrelevant details" only wound up making the whole exercise more confusing, maybe that's the point since this is a real world situation? It seems the obvious correct answer is that the incorrect window is specified for hwndParent, as many have pointed out; however, that simple answer is now completely overshadowed by the "irrelevant details" on why there's a difference between TaskDialog and MessageBox (I'm leaning towards Pierre's theory), and how the use of incorrect hwndParent ultimately leads to the wrong window becoming active (perhaps a surface symptom of a more serious issue triggered by hwndMainFrame being re-enabled prematurely?)

And it's amusing that the whole *topic* itself was for a short time sidetracked by the irrelevant topic of diaeresis. Yeah, this blog entry has become more interesting all right, for better or for worse. :p

[Yup, real-life debugging is full of irrelevant details. (And missing details too!) -Raymond]
Mordachai says:

January 26, 2011 at 10:56 am

Raymond seems to answer this in his linked series (#5):

blogs.msdn.com/…/379635.aspx

"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."

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

A "redesign" after 2019 erased thousands of user's comments from previous years. As many have stated, the comments are nearly as important as the postings themselves. The archived copies of the postings contained here retain the original comments.
The blog has changed domains many times and the urls have otherwise been under constant change since 2003. Even when proper redirection has been set up for those links, redirection only works for a limited period of time. For example, all of the internal blog links that were valid in early 2019, were broken by 2020 without proper redirection.
The blog has been under constant re-design and re-theming since its inception. It is downright irritating to deal with a bogged-down site experience as the result of the latest visual themes designed for cell-phone browsers. As of this writing, it is cumbersome to navigate titles with only 10 entries per page. While it is nice that the official site has a search feature, searching using this index (with all titles on a single page) is much quicker (CTRL-F in most browsers).

<-- Back to Old New Thing Archive Index