Return to Question

⚠️ The following sections are not important for my question but maybe for your answer. If you are about to write something like "that's not possible", I would be happy if you could read them and carefully think about it first.

However, I must beg you: Please do NOT start a discussion on the implementation details. I'm not so much interested in implementing this myself. That's why I asked on superuser.com and not on stackoverflow.com.

Similar Problems With Solutions

I'm positive that is possible to intercept calls that create modal dialogs; after all, there are solutions for similar problems:

• Any non-resizeable dialog can be made resizeable using ResizeEnable.
  _{Fun (or sad?) fact: ResizeEnable was last updated in 2003 but still works for Windows 10 without any problems. (Windows XP released in 2001, but from ResizeEnable's change log it seems like the author did not use XP at the time of the last release.)}

• Many fullscreen-only applications can be run in a window using DxWnd.

Technical Details

I'm very well aware that modal dialogs can return a value and that the application cannot simply continue without that return value. However, a workaround must be possible at least in theory:

If a UI library offers a way to use modal dialogs with return values, then that library also has to implement a way to pause the current thread and show the modal dialog in another thread such that the modal dialog can be interacted with. This applies even to single threaded UIs (which seem to be the standard). For example, in Java Swing the event dispatch thread (ETD) offers the method createSecondaryLoop() which is used by Swing itself to implement modal dialogs with return values. Usually these methods also move UI control to the new thread such that the background window is not frozen. This applies even to Windows explorer, as demonstrated in this screen cast (video plays in background while a modal dialog is open):

We can use that functionality too. The general approach is then:

• Intercept the call that would create a modal dialog
• Use the UI library's own functionality to pause the current thread and move UI control to a new thread
• Create and show an equivalent non-modal dialog
• When the dialog is closed, retrieve the data for the return value
• Use the UI library's own functionality to resume the original UI thread
• Return the data from the non-modal dialog

.

However, I must beg you: Please do NOT start a discussion on the implementation details. I'm not so much interested in implementing this myself. That's why I asked on superuser.com and not on stackoverflow.com.

Is there a tool* to make modal windows non-modal?
_{* You may substitute the term »tool« by hack, patch, or whatever comes to your mind.}

If the UI library offers a way to use modal dialogs with return values, then that library also has to implement a way to pause the current thread and show the modal dialog in another thread such that the modal dialog can be interacted with. This applies even to single threaded UIs (which seem to be the standard)! For example, in Java Swing the event dispatch thread (ETD) offers the method createSecondaryLoop() which is used by Swing itself to implement modal dialogs with return values. We can use that functionality too. The general approach is then:

• Intercept the call that would create a modal dialog
• Use the UI library's own functionality to pause the current thread and move UI processing to a new thread
• Create and show an equivalent non-modal dialog
• When the dialog is closed, retrieve the data for the return value
• Use the UI library's own functionality to resume the original UI thread
• Return the data from the non-modal dialog

❓ Is there a tool* to make modal windows non-modal?
_{* You may substitute the term »tool« by hack, patch, or whatever comes to your mind.}

⚠️ The following sections are not important for my question but maybe for your answer. If you are about to write something like "that's not possible", I would be happy if you could read them and carefully think about it first.

If a UI library offers a way to use modal dialogs with return values, then that library also has to implement a way to pause the current thread and show the modal dialog in another thread such that the modal dialog can be interacted with. This applies even to single threaded UIs (which seem to be the standard). For example, in Java Swing the event dispatch thread (ETD) offers the method createSecondaryLoop() which is used by Swing itself to implement modal dialogs with return values. Usually these methods also move UI control to the new thread such that the background window is not frozen. This applies even to Windows explorer, as demonstrated in this screen cast (video plays in background while a modal dialog is open):

We can use that functionality too. The general approach is then:

• Intercept the call that would create a modal dialog
• Use the UI library's own functionality to pause the current thread and move UI control to a new thread
• Create and show an equivalent non-modal dialog
• When the dialog is closed, retrieve the data for the return value
• Use the UI library's own functionality to resume the original UI thread
• Return the data from the non-modal dialog