Timeline for Unmodalize Dialogs (Make Modal Dialogs Non-Modal)
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 16, 2020 at 11:24 | comment | added | harrymc | In any case, the answer to your question is : You can re-enable the main window and unfreeze it using AutoHotkey or similar. How well the deblocked window will work is unknown, needing experimenting per each case. | |
| Jun 16, 2020 at 11:22 | comment | added | harrymc | It's the operating system that does it, not Java or C or any library. And yes, the modal dialog starts a new message pump serviced by a new thread (it has to, as the old one is blocked). Some events that arrive at the blocked message pump are still serviced, not all are queued. The same mechanism is used as for recursive procedure calls, so the old event call is kept on the stack for the duration while the same thread handles the new event. There is no documentation about what the behavior of different calls is in such a situation. | |
| Jun 16, 2020 at 10:51 | comment | added | Socowi | At least in Java Swing all events are sent to the new thread when opening a modal dialog. When the modal dialog is closed, all events are sent to the old thread again. Queued events are shoved between threads too. Nothing is lost. The only thing which gets blocked is the event waiting for the dialog's return value. The background window remains fully functional, but user interaction with it is just discarded. Of course other UI libraries might do things differently. But looking at this screencast it seems like Windows Explorer uses a similar approach. | |
| Jun 16, 2020 at 9:52 | comment | added | harrymc | Understand also that the queued events are not necessarily presented to the message pump in the order in which they occurred. You might for example deblock the main window and type a value into a field and click a button, to find that the click was processed before the value was changed, with wrong results. It would be pretty hard in such case to understand why the program was misbehaving. | |
| Jun 16, 2020 at 9:39 | comment | added | harrymc | I was trying to read your question in a way that can work. Yes, you can re-enable the main window and unfreeze it using AutoHotkey. However, regarding message pumps in GUI programs, you should understand that the main window's message pump is associated with the main thread which is blocked waiting for the dialog to terminate. New event messages coming to the main window will not be treated because there is no thread to handle them, so they will just be queued. You would be entering values that are not checked and clicking buttons with delayed action, with effects that are not easy to predict. | |
| Jun 16, 2020 at 8:55 | comment | added | Socowi |
Thank you for your answer, but I'm afraid there is a big misunderstanding here: "you are asking for ways to automate answering/clicking specific dialogs". No, that's not I want to do. I want to keep a modal dialog open (e.g. a settings dialog) and switch back and forth between that dialog and its main window, interacting with both at the same time. Not sure how I failed to communicate this. If you have some hints on what gave you this idea, I might be able to improve my question. ... Maybe I can add a mock screencast of Windows Explorer where I show the expected behavior after the change.
|
|
| Jun 16, 2020 at 8:47 | history | answered | harrymc | CC BY-SA 4.0 |
