Nelson Minar wrote:
> >The closest thing I've found to relevant information is in the
> >documentation for Swing -- which states explicitly that Swing is not
> >thread-safe, and that all GUI access, after the GUI is instantiated,
> >needs to happen from the AWT Event thread.
>
> This is certainly a requirement I can live with. But in this case,
> the dispose() only happens in an AWT Event thread. It's called when
> the user clicks on a button (stackframe included again)
Oh, well... nice theory while it lasted :-(.
> >On the other hand, I've found that adopting Swing's approach has
> >solved my GUI reliability problems. Norm's approach sounds
> >suspiciously similar.
>
> Actually, isn't it exactly the opposite, putting the call to Swing
> in some non-Swing thread?
I spoke too loosely. You're right, Norm's approach isn't much different from not doing
anything at
all: in either case, the GUI code (dispose) is being called from somewhere other than
the AWT Event
thread.
The issue, as the Swing documentation points out, isn't about confining GUI access to
one particular
thread, it's about confining it to one thread *at a time*. Forcing everything into the
AWT Event
thread is a way to do that. Norm is doing something similar by putting the activity
into a
low-priority thread -- it's most likely to execute at a time that nothing else is
going on.
Nathan Meyers
[EMAIL PROTECTED]
