Re: Swing/Thread ShortCut - Bad Style or Good Idea?
Hal Vaughan wrote:
Is this a good shortcut or a bad idea because of other consequences that I
may not be aware of? Is it something that could be done depending on what
the other methods it calls do?
Yes, it depends very much on what methods you invoke.
First, realize that Swing uses threads to synchronize shared objects.
That is, if you modify any Swing component, you must do so on the EDT
thread or you will get weird, hard to debug error appearing
intermittently in your code.
There are a few methods which are safe to call from threads other than
the EDT. repaint(), invalidate(), and revalidate() all come to mind.
Also, setText() for the JText objects can be called safely anywhere.
Check the documentation carefully. If a method is not noted as being
thread safe, it ain't.
Finally, synchronization is pretty easy. Just call
java.awt.EventQueue.invokeAndWait() with another Runnable from with in
your worker thread and you'll be all synchronized. There's also
invokeLater(), but invokeAndWait is likely to be a bit easier to
understand because it's synchronous.
With all that out of the way, yes it's a very good idea to have long
running tasks run on threads outside the EDT, just like you've shown.
Best idea since the Jacquard loom.
I don't however like the idea of testing for which buttons invoked the
event, from inside your thread. It smacks of maintenance issues.
Better to make a simple method that doesn't know anything about GUIs or
buttons or text areas or anything, and just call that directly from one
action listener. Simpler this way in the long run, even if it's more
typing.
OK, my 2 nickels. And I still want to know if that code for
non-focusable windows works in your environment too. ^_^