-
Bug
-
Resolution: Won't Fix
-
P4
-
None
-
1.1.2
-
generic
-
solaris_2.5.1
The current code for handling modal dialogs includes a bunch of stuff from 1.0.2 that is no longer necessary in 1.1.x. In particular, when the show() method for a modal dialog blocks, there is no need to re-enter the event handling loop. There is already a separate thread handling the low-level X events or win32 messages, and if necessary, there is also a separate EventDispatchThread. The show() method only needs to wait until the modal dialog is unmapped.
The dialog peer code also forks a separate thread to do the blocking show() call. The comment explains that this is done to avoid event handling with
unsecure classes on the stack. I don't understand the issue there, but it's
irrelevant because the show() call doesn't need to re-enter the event loop.
I've attached patches for the Solaris (X/Motif) version. The win32 code
appears to have the same problem. (Someone might also want to check my
code for awt_modalWait_loop. I wasn't sure of the best way to wait, so I just made it wait for the AWT_LOCK and check if the modal dialog is unmapped every
time the thread is notified.)
robert.wilson@Eng 1997-06-17
The dialog peer code also forks a separate thread to do the blocking show() call. The comment explains that this is done to avoid event handling with
unsecure classes on the stack. I don't understand the issue there, but it's
irrelevant because the show() call doesn't need to re-enter the event loop.
I've attached patches for the Solaris (X/Motif) version. The win32 code
appears to have the same problem. (Someone might also want to check my
code for awt_modalWait_loop. I wasn't sure of the best way to wait, so I just made it wait for the AWT_LOCK and check if the modal dialog is unmapped every
time the thread is notified.)
robert.wilson@Eng 1997-06-17