Submission details
A parent window should still be moveable, resizable when a modal dialog is opened.
A dialog box is a window which requires the user to interact with it, preventing the workflow on its parent window. Windows too simplistic implementation blocks all interactivity with the parent window, beeping every clicks in its area including its non-client area. Consequently, the window can neither be moved, resized, minimized nor maximized until the modal dialog box is closed.
In attached picture scenario, I want to copy Aero Taskforce web site subtitle as my Notepad file name. I don't want to move my internet browser (here docked) to make the subtitle visible, just move the Notepad main window a little on the right... => I have to dismiss first the modal dialog.
A modal dialog box should block only the client area (i.e. its content area), thus allowing access to its parent window layout commands which are always orthogonal to concepts and data the modal dialog is blocking.
High
High
Not fixed
Discussion (9 comments)
I think you don't read me carefully...
Yes, a modal dialog should block application all other workflows but moving or resizing a window is independent from the workflow is hosting.
Windows is a multitask system, multiple applications with ui are running concurrently. Hiding an information with a parent window when this information is required in modal dialog is a very annoying situation in Windows (see posted picture). The worst scenario I can think of, is a old style installer, maximized and flagged always visible with a modal progress modal dialog box.
OSX handles this better : a modal dialog is docked to it's parent window and shares its parent caption. Thus, both of them are moveable. This solution is however not ideal because the docked dialog is not moveable and hides parent content.
Changed problem description.
Added new image attachment.
+1 Eirther way you should still see other infomation incase you want to save later or need to see some text to use as the title....
My only concern is any problems this might cause for custom drawn (GDI+) controls that would be shown on resize.
+1 anyway.
+1
MacOSX does this brilliantly, I'd love to see this finally fixed in windows also, even if not in the same exact way.
Yep, it's by design. The design is flawed as described. But even without knowing many internal specifics, I can foresee several fatal consequences to making the suggested changes.
For instance, even though the windowing manager handles the resize/move, the dialog is alerted when and while these happen, so it can update it's layout or whatever. But every app coded to date expects not to receive such alerts while displaying a modal dialog. Result: Hello crash!
Furthermore, full-skinned windows (that is, without non-client areas), plague as they are, wouldn't move/resize as the user would expect because they handle such operations themselves, mimicking the windowing manager, but they don't actually receive the input.
So, even if the problem exists and the suggestion is very valid, I think it has a very low chance of ever being implemented.
@Turbo
I understand technical implications but this is the very reason Windows is not evolving, things even simplest can't be done because of compatibility issues. DWM is so poor today because of Win32 interop, shared fat registry is a hell, there are tons of examples...
It must stop. We want a tech up to date Windows and if we need to throw old Windows 95 apps, its really really OK for me. Developers community is ready to update apps if things are better, easier and sexy! Look at Apple world. If Microsoft wants to decline multiple versions of Windows then OK, build a historical hyper patched Windows fully compatible and a light new optimized and tech up to date Windows. Virtualization can be the answer.
And to respond to the "low chance of ever being implemented", no it's possible to set a flag in new apps manifest to enable the corrected design. Lot of things work already like that in API.
Ahh This is a God send feature in OS X/Linux systems. It makes GUI a lot unconstrained and open!
If you don't believe me, PLEASE, I beg you to try and work a little with an OS X or Linux for a couple of hours and you will see an improvement!
+100!!
-1
Modal dialog are hooked to their parent window, so that means you can easily make the TaskForce site the active window (bring it to front), get the text you need, and then restore the Notepad window and it's modal dialog.
bearluke wrote on August 17, 2008, 3:16pm
-1
a modal dialog works in this way, it's by design. A modal window blocks all other workflow in the program until the modal window is closed. Frequent uses of modal windows include: drawing attention to vital pieces of information, blocking the application flow until information required to continue is entered, collecting application configuration options in a centralized dialog (In such cases, typically the changes are applied upon closing the dialog, and access to the application is disabled while the edits are being made), etc