Modality, part 6: Interacting with a program that has gone modal

Date:February 28, 2005 / year-entry #48
Tags:code;modality
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20050228-00/?p=36343
Comments:    14
Summary:Earlier we saw the importance of setting the right owner window for modal UI. It is also important, when manipulating a window, to respect its modality. For example, consider the program we ended up with last time, the one which calls the MessageBox function to display a modal dialog. If we wanted to get that...

Earlier we saw the importance of setting the right owner window for modal UI. It is also important, when manipulating a window, to respect its modality. For example, consider the program we ended up with last time, the one which calls the MessageBox function to display a modal dialog. If we wanted to get that program to exit and sent a WM_CLOSE message to the main window instead of its modal popup, the main window would likely exit and leave the message box stranded, resulting in the same stack trace without support we saw in part 4.

Respect the modality of a window. If it is disabled, don't try to get it to do things; it's disabled because it doesn't want to do anything right now. You can go hunting for its modal pop-up and talk to that pop-up. (Unless, of course, that pop-up is itself disabled, in which case you get to keep on hunting.)

Comments (14)
  1. Ben Hutchings says:
    February 28, 2005 at 7:19 am

    In what situation might one want to do this?

  2. Jonathan Payne says:
    February 28, 2005 at 7:55 am

    Is this why DDE is never fun when you have modal UI (particularly at startup)?

  3. Raymond Chen says:
    February 28, 2005 at 9:29 am

    Ben Hutchings: Here are some people who came up with scenarios.

    http://groups-beta.google.com/group/comp.os.ms-windows.programmer.misc/msg/52ef7ee60cc49e1d

    http://groups-beta.google.com/group/comp.lang.pascal.borland/msg/a1f5b6837a83328f

    http://groups-beta.google.com/group/comp.os.ms-windows.programmer.tools.mfc/msg/4085514837393c57

    Jonathan Payne: This is just one of the many reasons why DDE is never fun…

  4. Rob Manderson says:
    February 28, 2005 at 8:46 pm

    I know it’s anthropomorphising but it’s not so much a case of windows are disabled because they don’t want to do anything right now – it’s more the case that some action they’ve caused would prefer that the parent window be disabled.

    Keep on writing Raymond – your blog is my number 1 read each morning.

  5. Isaac Chen says:
    February 28, 2005 at 9:48 pm

    In http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowfeatures.asp

    "The system automatically destroys an owned window when its owner is destroyed."

    And as you said, we should set the owner of the pop up (or message box) properly. So we don’t seem to have a problem if WM_CLOSE is sent to (and processed by) the owner of the pop up (or message box). They both should be destroyed and thus leaving no stranded window (main or pop up/message box).

    Am I missing something?

  6. Raymond Chen says:
    March 1, 2005 at 5:29 am

    Clearly something is wrong or the people in the messages I linked to are hallucinating. I already mentioned two reasons in the article.

  7. Ben Hutchings says:
    March 1, 2005 at 5:38 am

    Raymond: In the first scenario, presumably EnumWindows temporarily blocks destruction of the windows whose handles it passes to the callback, so that the handles are guaranteed to be valid, but does it also block creation and destruction of pop-up windows? If not, there seems to be a race condition in between use of GetLastActivePopup() and processing of WM_CLOSE. The second and third scenarios seem to me to be cases where the programmer needs to fix the structure of the application.

  8. Raymond Chen says:
    March 1, 2005 at 8:52 am

    EnumWindows blocks nothing. If it did, imagine the havoc you could cause by calling EnumWindows and then calling MessageBox in your callback.

  9. Waleri says:
    March 1, 2005 at 9:11 am

    In other words, one cannot send WM_CLOSE blindly around. Problem is that MSDN didn’t warn about that at all in the description of WM_CLOSE. Q178893 mentions that WM_CLOSE may not terminate the process. IMHO, since it isn’t forbidden to send WM_CLOSE to a disabled window, applications should be able to handle this situation correctly.

  10. Ben Hutchings says:
    March 1, 2005 at 11:14 am

    Raymond: So does that mean that any program that uses another thread’s window handles has unavoidable race conditions?

  11. Raymond Chen says:
    March 1, 2005 at 11:50 am

    "Does that mean that any program that uses another thread’s window handles has unavoidable race conditions?"

    Indeed that has always been the case in Win32 if you do this without the cooperation of the target window.

  12. Ben Hutchings says:
    March 1, 2005 at 7:33 pm

    That’s kind of what I suspected. It makes me think it was a mistake to try to maintain the window messaging model in a preemptive multitasking environment.

  13. haroon says:
    March 3, 2005 at 12:08 pm

    Thanks for the interesting articles. I have read all seven. I have a situation which I think is arising from what you mentioned in part 6. However, I am not sure how to work around it. I have an MDI application in which MainFrame is also an event sink. To make things interesting, Modal dialogs are also invoked in these connection points. If MDI is displaying a modal dialog, I could get another modal dialog from connection point callback. This is fairly common scenario upon startup. Now the MDI has two modal dialogs. MainFrame is disabled and user can switch between the two modal dialogs. Is this is a valid behavior? i.e. having two modal dialogs at a time for one owner(MainFrame). Also, one of them, if closed last, can enable MainFrame. I am not sure how to ensure

    a) one modal dialog at a time, and

    b) MainFrame is only enabled after all the modal dialogs are gone.

  14. Raymond Chen says:
    March 4, 2005 at 12:09 pm

    This was already discussed in part 5.

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