On Tue, 05 Feb 2008 17:05:27 -0800, Daniel Pitts
<newsgroup.spamfilter@virtualinfinity.net> wrote:
If you don't know what the EDT is, then you are likely doing something
wrong. I suggest looking at the sun tutorial on Swing and threads.
<http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html>
Hmmm. Well, that article seems to say that my code is perfectly fine.
It specifically calls out initialization as something that's okay to do
in the main thread. My code in fact looks a lot like the sample they
offer: a bunch of initialization in the main() method, with the last
thing being a call to show() (in my case, setVisible(true), per the Java
docs saying that show() is deprecated in favor of setVisible(true)).
I'm familiar with the issues relating to using GUI objects on a thread
other than where they are created, having a fair amount of experience
writing to both the Windows and Mac OS API, both of which are very
strict about making sure you create the object on the same thread where
the message pump for the object will be run (for example, on Windows you
won't even get messages for a given window instance except on the thread
where that window was created, so you must always have a message pump on
the thread where the object was created, and the OS will always marshal
calls to the window procedure across to the correct thread).
But my reading of the Java docs I've seen, and the article you've
offered, suggest that in Java, the objects can in fact be created on a
different thread from where their events will actually be processed, and
not only that, that it's a reasonably common technique. The only rule
is that once the object has been shown, it must only be interacted with
on the EDT.
Ah, I must have linked to an out-dated article. I read that they
The best experiment would be to provide an SSCCE. Something that simply