| Date: | February 21, 2005 / year-entry #43 |
| Tags: | code;modality |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20050221-00/?p=36403 |
| Comments: | 19 |
| Summary: | Last time, we saw an example of code that was UI-modal but not code-modal. The opposite is also true: You can have code-modality without UI-modality. In fact, this is far more common than the UI-modal-but-not-code-modal scenario. You encounter modal loops without a visible change in UI state when you drag the scroll bar thumb, drag... |
You encounter modal loops without a visible change in UI state when you drag the scroll bar thumb, drag the window caption, display a pop-up menu, or initiate an OLE drag/drop operation, among other places. Any time a nested message loop is constructed, you have code modality. One example is given in MSDN, where the |
Comments (19)
Comments are closed. |
I’m guessing the point of these modality articles is to point out the pitfalls of code modality without UI modality? In my experience it seems every time I have code modality it leads to trouble (due to re-entrancy or other unexpected interactions with the outer event loop). State machines or threads are more difficult to write than modal code but seem like the only alternative.
Found QBasic, should anyone care:
http://download.microsoft.com/download/win95upg/tool_s/1.0/W95/EN-US/olddos.exe
(Also, an edit button for comments would be nice. :)
Why doesn’t CreateDialog/DialogBox has a bit-flag if it should be modal?
"12 lines of text is enough for everyone."
CreateDialog is the modeless function and DialogBox the modal one. If you really want one function with a bit-flag you are free to write it yourself.
CustomFunction(…, BOOL fModal)
{
if (fModal) DialogBox(…);
else CreateDialog(…);
}
When are you going to address the even more important issue of Code morality? :)
modality schmodality. stop making excuses, i want tabbed browsing.
That’s the IE team, second door on your left.
Don’t tab my browser; I don’t want to have to go to yet another place to switch between windows, the taskbar and Alt-Tab work perfectly well for that.
When a window is in menu mode, it seems that all WM_MOUSEMOVE messages in the same message queue are dispatched to that window rather than their original windows. Why is it so?
Zd: so that it can figure out where the mouse is so it can tear down the Window when you click outside of it, given that the menu neither gets focus nor activation.
Do a search for "Fakemenu" – which is one of Raymond Chen’s wonderful example pieces of code, and invaluable for those who want to learn the finer points of making Windows sit up and beg – on Google Groups.
Oh, and Zd, there’s a little addenda for that:
It’s also so that your message loop – which might have its own translation and pre-translation code in it – doesn’t interfere with the operation of the menu. So it just pushes it entirely out of the equation until it’s done.
I remember back in the dim and distant days I wrote a bunch of GUI-type code in, horror of horrors, QBasic, and trying to maintain state during various interactions was tricky, but worth the effort.
The first iteration was completely modal (in a manner of speaking) — if a window popped up, nothing else could happen (GUI-wise) in the underlying application until the popup was closed. However, this somewhat limited its usefulness, so the second iteration went to the other extreme and (unless the application writer deliberately interfered with the "message queue") everything was non-modal; rather counterintuitively the second iteration wound up being significantly shorter and more elegant (although I guess that’s in some part due to the fact that I’d learned a lot of lessons from v1).
The relevance? Ever since then I’ve tried my best to avoid any sort of modal situation; apart from one or two edge-cases it’s not neccessary, and is almost universally irritating — I’d wager that everyone reading this has, at one time or another, navigated through a series of modal dialogs only to realise that some vital piece of information they need is now hidden by a previous level of dialog neccessitating a quick backtrack. Even if Windows would let you *move* the windows stuck underneath it’d be an improvement…
(As an aside, does anyone have a copy of QBasic or where I can get one? I must confess to having a soft spot for it, but I seem to have discarded my last remaining copy of Win95. Sure, it’s of little practical use these days, but I want to throw me some bananas! :)
(As another aside, does anyone else get annoyed with the piddly little text box for entering comments here? It’s a pain having to fire up Notepad every time, but it’s almost impossible to proofread anything if you can only see 12 lines of 48-column text; it’s like using the C64 all over again, only worse!)
This is horribly offtopic here but doesn’t anybody remeber that tabbed browsing was in IE long before Mozilla and Firefox even existed? IE 3.x (or was it 4.x?) had tabbed browsing. I’m glad it was removed (you can’t switch to a specific tab from a different app) but it might have been a user option like it is today in the other browsers.
This is horribly offtopic here but doesn’t anybody remeber that tabbed browsing was in IE long before Mozilla and Firefox even existed? IE 3.x (or was it 4.x?) had tabbed browsing. I’m glad it was removed (you can’t switch to a specific tab from a different app) but it might have been a user option like it is today in the other browsers.
Ive never found a good reference describing things like modality in the context of code and UI.
Anyway, when the user is engaged in a modal drag operation I would have thought that the UI was modal – I mean – the user is quite obviously stuck on that scrollbar until they let go of the mouse.
The WM_QUIT message lets multiple modal loops communicate with each other.
Aside of backwards compatibility, I don’t see why nested pumps are needed at all.
Aside from backwards compatability with what?
Modal pumps arn’t *needed*, theyre just very convenient to localize functionality.
"Aside from backwards compatibility" just seems a safe thing to say, being that it seems like the perennial fallback explanation to every quirk.
With a little planning, I think functionality can be just as conveniently localized *without* modal pumps. But nobody I’ve ever worked with would take the time to (a) work it out, and (b) admire the elegance of the finished code as opposed to a modal hack.
This might all stem from my sky-is-falling mentality that wonders what my code would do if some goofy utility re-enabled the parent window of a dialog box.