<AWT Dev> Problem with modal Dialog

Roman Kennke roman.kennke at aicas.com
Mon Feb 16 12:08:48 PST 2009


Hi,

>>>>>>>> BTW, simply sending this over the EQ is no solution either, because
>>>>>>>> then
>>>>>>>> later it will fail to invokeAndWait(). I will think a little more
>>>>>>>> about
>>>>>>>> this, or maybe anybody has a quick idea?
>>>>>>> Just an idea (have not evaluated it carefully):
>>>>>>> perhaps we should set keepBlockingEDT to false not in
>>>>>>> hideAndDisposeHandler(),
>>>>>>> but in WakingRunnable.run() instead.
>>>>>> I'm looking at this problem at the moment. The problem is the instance
>>>>>> of WakingRunnable is not run on EDT at all - I don't know why.
>>>>> I know why. It is because the DisposeAction is run _immediately_, before
>>>>> the WakingRunnable had a chance. This DisposeAction calls removeNotify(),
>>>>> which leads to all events on the EQ that are related to the Dialog beeing
>>>>> discarded.
>>>> Could you, please, point to the place where all the events are discarded?
>>>> I don't see any.
>>> In Component.removeNotify(), we call this:
>>>
>>> Toolkit.getEventQueue().removeSourceEvents(this, false);
>> OK, I see. What a wonderful code...
>>
>>> which removes all events related to the component. removeNotify() is
>>> called from inside the DisposeAction.
>> For this particular case it's enough to add some additional check to
>> hideAndDisposeHandler:
>>
>>         if (showAppContext != curAppContext) {
>>             // Wake up event dispatch thread on which the dialog was
>>             // initially shown
>>             SunToolkit.postEvent(showAppContext, wakingEvent);
>>             showAppContext = null;
>> +        } else if (EventQueue.isDispatchThread()) {
>> +            waking.run();
>>         } else {
>>             Toolkit.getEventQueue().postEvent(wakingEvent);
>>         }
> 
> this change will fix this particular test, but the same problem may
> exists even when
> we call hide() not on EDT, it is just a little bit harder to write
> test for this ;)
> 
> What about moving resetting keepBlockingEDT to WakingEvent.run(), or,
> perhaps, we can simply change
> target of WakingEvent from a dialog to toolkit.
> What do you think?

Setting the target of the WakingEvent to the toolkit sounds like an 
elegant and efficient solution to me. Simply executing the event 
directly when on the EDT (as Artem proposed) sounds like crying for more 
side-effects.

/Roman


-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt



More information about the awt-dev mailing list