<AWT Dev> Problem with modal Dialog

[Oleg Sukhodolsky]

On Fri, Feb 13, 2009 at 11:31 PM, Roman Kennke <roman.kennke at aicas.com> wrote:
> Hi Oleg,
>
>> as far as I can see hideAndDisposeHandler() called either from hide()
>> (if it is not called by dispose()) or
>> from doDispose(), but after super.doDispose() is executed.
>
> You are right. My original analysis was not correct. The problem is a little
> diferent, the application I have here calls hide() and dispose() one after
> the other, which then causes this situation, hideAndDisposeHandler() called
> first, followed quickly by Window.doDispose(). The attached test program
> demonstrates the problem. Not executing the DisposeAction immediately, but
> instead sending it over the EQ solves the problem by bringing the actions
> into correct order. This would be a good case for testing the brand new
> bugzilla, no? ;-)

Yes,  I agree with you.  Now you have good bugreport (and good bug to
report ;) to test
new system :)

Oleg.
>
> /Roman
>
>  So, from
>>
>> your description it is not clear
>> how Window.doDispose() for the dialog can be executed after
>> hideAndDisposeHandler() :(
>>
>> Perhaps if you start your description from the very top of the call
>> stack it would provide enough information
>> to understand that.
>>
>> With best regards, Oleg.
>>
>> On Fri, Feb 13, 2009 at 7:54 PM, Roman Kennke <roman.kennke at aicas.com>
>> wrote:
>>>
>>> Hi there,
>>>
>>> I have a strange problem with modal dialogs here. I have a modal dialog,
>>> which is never released, even though it is disposed. What happens is
>>> this:
>>> in Dialog.hideAndDisposeHandler() the waking event is correctly posted to
>>> the EQ. Then doDispose() continues in Window.doDispose(), where a
>>> DisposeAction is created. Then it finds that it is on the EDT and
>>> immediately executes this action. This in turn calls removeNotify(),
>>> which
>>> then leads to all events that are related to the dialog to be removed
>>> from
>>> the EQ, including the waking event. Thus, the Dialog is never released
>>> and
>>> the thread that opened the dialog is stuck forever, since nobody will
>>> notify() it. It can easily be solved in Window.doDispose(), just remove
>>> that
>>> if (EventQueue.isDispatchThread()) check.
>>>
>>> Unfortunately I have no easy testcase to reproduce. I found this in
>>> JamaicaVM w/ DirectFB/Caciocavallo. It is not unlikely that this only
>>> happens because we have different thread scheduling than Hotspot, or I
>>> might
>>> even think wrong and something is missing to me.
>>>
>>> Any ideas? Is this a bug? Am I thinking in the wrong direction?
>>>
>>> /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
>>>
>
>
> --
> 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
>