Modality, part 2: Code-modality vs UI-modality

Date:February 21, 2005 / year-entry #43
Orig Link:
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...

Comments (19)
  1. Dan Maas says:

    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.

  2. Mat Hall says:

    Found QBasic, should anyone care:

    (Also, an edit button for comments would be nice. :)

  3. Billy Boy says:

    Why doesn’t CreateDialog/DialogBox has a bit-flag if it should be modal?

    "12 lines of text is enough for everyone."

  4. Raymond Chen says:

    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(…);


  5. Jon Potter says:

    When are you going to address the even more important issue of Code morality? :)

  6. .ten says:

    modality schmodality. stop making excuses, i want tabbed browsing.

  7. Cooney says:

    That’s the IE team, second door on your left.

  8. Jeremy Morton [MSFT] says:

    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.

  9. zd says:

    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?

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

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

  12. Mat Hall says:

    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!)

  13. Jerry Pisk says:

    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.

  14. Jerry Pisk says:

    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.

  15. Chris Becke says:

    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.

  16. The WM_QUIT message lets multiple modal loops communicate with each other.

  17. Aside of backwards compatibility, I don’t see why nested pumps are needed at all.

  18. Chris Becke says:

    Aside from backwards compatability with what?

    Modal pumps arn’t *needed*, theyre just very convenient to localize functionality.

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

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:

<-- Back to Old New Thing Archive Index