<AWT Dev> Problem with modal Dialog

[Roman Kennke]

Hi there,

> >>>>>>>> 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.

So what should we do about it?

/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