Is the Task Dialog modal within its parent window or systemwide?
Long story short: Currently there is no way to make a dialog modal with respect to only one window.
IE: I want to be able to minimize MSWord even if it has a modal dialog popped up. Currently this is not possible. Every program when popping up a modal dialog completely hijacks the screen. The only way around this is the: 'Show Desktop' button.
Mac OS X already does this. It has modal windows attached to parent windows only.
In windows Vista the 'play well with others' concept would greatly benefit if a modeless dialog still allowed me to minimize the window that popped the dialog up.
[625 byte] By [
blunose] at [2007-12-18]
Win32 doesn't have system modal dialogs any more. All dialogs are modal to their owner.
In general, the modality of windows hasn't changed in Vista. If a modal dialog is up, there's no way to get its parent to minimize. This was a conscious decision, in no small part because sheets (the Mac OS implementation to which you refer) are not movable with respect to the parent window. If you are interested in seeing content in the main window while the dialog is up, that's not possible.
Of course, this approach as we've implemented it so far has the disadvantage you mention, that a window doesn't like to minimize. As we are able to rely more on the new window management platform (DWM, which requires newer hardware), we should be able to break away more easily from legacy decisions like this.
jeff
This is exactly what I was wondering about. I mentioned this idea on some other forums a while back and got a ton of flak from well meaning readers of the Raymond Chen blog for suggesting a potentially breaking change. Seeing as I am a coder too, one who's had to support a bit of commercial software and APIs I can perfectly understand that impulse. I even applaud it. But they seemed so fond with finding issues like: "resizing the parent should not be allowed, because controls hosted in the parent might respond to those events by formatting the hard drive etc, etc..."
Well to that I say: If you were doing some crazy stuff when responding to your parent's resize, minimize and maximize events then you are probably in trouble already. :)
I realize that many convoluted cases can be created that make my suggestion become unworkable. However, the existing window manager can also be broken if you try hard enough, as Raymond tirelessly explains.
I just think that the screen real estate is too precious a commodity to be monopolized by a single app. If I am using an application that can't save a file because it already exists (thereby popping up a modal dialog) it should gracefully recede control of my screen and minimize until such time as I want to answer that question.
An actual example of this is an earlier version of the Microsoft Windows Update dialog, which was 'modal' within the IE window only. I understand that my usage of the term 'modal' may be misleading, I'd prefer to use the term: 'attached'. You could still minimize IE and have it not clutter your screen space.
Lastly, I am not trying to offend anyone by claiming that the existing system is less than adequate. Its a fabulously functional system, but the times have moved on, and with the advent of the TaskWindow dialog in Vista, much could be improved without jeopardizing backwards compatibility.
There's definitely room for improvement here. However, no significant new modalities for dialog boxes have been introduced, even for TaskDialog.
It sounds like it's too much work to have this functionality in Vista.
Perhaps in the next version of windows it will be possible to minimize an application that is waiting for user input via the modal dialogs.
I'd certainly consider it to be a significant improvement in the UI in terms of multitasking.
Like some wise man said once: A lot of little frustrations contribute to an overall feeling of unhappiness. And guess what generates a lot of little frustrations? Lack of control over your environment of course :)!
Cheers, and thanks for your comments.
blunose, neither do i like this behaviour, as you describe it!
hope they will get rid of it in the future or at least make it possible for the app developers...
"Or at least make it possible for the app developers."
It has been possible for app developers since 1983: pass an intermediate hidden owner. Then the modal dialog will disable the intermediate window, leaving the visible owner unaffected.
Thanks for your reply Raymond, but I am somewhat unsure by what exactly this achieves. I tried what I thought you suggest, and all that did for me is that the immediate owner of the modal dialog was invisible, but the window that launched the owner was still inaccessible, because after all a modal window disables all other windows in the same process.[i'd be happy to be disproved on that one :)]
Could you give a few lines of pseudocode or Win32 code?
Thanks.
It is hardly the case that a modal window disables all other windows in the process. It only disables its immediate owner. Try it: Open two Explorer windows (both in the same process) and in one of them select Tools.Options. The Options dialog is modal to the window that is its owner, but notice that the other Explorer window is just fine.
Hm, I stand corrected. However my original problem remains. An open Tools.Options dialog still prevents the minimization of the explorer window that launched it.
[By the way I was using C# and Windows Forms in my attempt to accomplish what you suggested. And in C# a single modeless window definitely disables all the others, as the code below demonstrates.]
<code>
private void button1_Click(object sender, System.EventArgs e){
Form1 f
= new Form1();f
.Show();Form1 f2
= new Form1();f2
.Show();Form1 f3
= new Form1();f3
.ShowDialog(f2);}
<code>
Why is form 'f' be disabled? Is there some hidden connection between 'f2' and 'f' that I am missing?
