Executing Code outside of the Event Dispatcher Thread
Hello,
I have just come to learn that any actionPerformed() method that is called after an event occurs actually runs in the Event Dispatcher. So, for example, if you click on a button, any code that is run as a result is run in the event dispatcher.
So there are two things I am wondering about. First, If i run code in response to a user event, then it doesn't have to use invokeLater() to update GUI components because it's already being run in the event thread? Second, if I run code in response to an event but it's computationally expensive and I do not want to run it in the Event Dispatcher thread, how do i do that? Will a method call cause it to do so, or do i have to specifically create a new thread for it?
My questions are a result of this: How does one normally go about updating a GUI during a long process? I figured that if I could get the process to run in any thread other than the Event Dispatcher, I could call invokeLater() within it and it would update the GUI. Am I correct in assuming so?
[1042 byte] By [
corrosivea] at [2007-10-3 8:47:44]
> My questions are a result of this: How does one
> normally go about updating a GUI during a long
> process? I figured that if I could get the process to
> run in any thread other than the Event Dispatcher, I
> could call invokeLater() within it and it would
> update the GUI. Am I correct in assuming so?
You are correct. This is the way to go.
One problem.
If I create a class that implements Runnable and run it in a separate thread, how do I update GUI components? I'll need a reference to the GUI, and unless I inherit from it, how can I do that? Should I use inner classes? I would prefer to keep them as separate classes within the same package.
Please advise.
> I'll need a reference to the GUI, and> unless I inherit from it, how can I do that?No, you do not need to inherit from it.Just take a reference in the constructor of the new thread object.
So there are two things I am wondering about. First, If i run code in response to a user event, then it doesn't have to use invokeLater() to update GUI components because it's already being run in the event thread?
Correct. So if your response to an action is, for example, creating a new bit of UI using data which is already in memory, you can just do it.
Second, if I run code in response to an event but it's computationally expensive and I do not want to run it in the Event Dispatcher thread, how do i do that? Will a method call cause it to do so, or do i have to specifically create a new thread for it?
You will need to create a new thread: method calls are just control flow within the same thread.
You should use an object which implements Runnable and then use "new Thread(foo).start()"
My questions are a result of this: How does one normally go about updating a GUI during a long process?
You have to hop back onto the EDT whenever an update is required. I'd suggest writing yourself a little reusable class or two to help you with this - such as a listener mechanism with an implementation which handles the thread hopping.
I figured that if I could get the process to run in any thread other than the Event Dispatcher, I could call invokeLater() within it and it would update the GUI. Am I correct in assuming so?
Yes.
Should I use inner classes? I would prefer to keep them as separate classes within the same package.
Depends on all sorts of things - sometimes anonymous or declared inner objects are the way forward, sometimes public class objects, sometimes generic helper objects and sometimes utility classes. There are all sorts of different scenarios. As I say, though, it's worth writing some utility/helper classes to reuse. Personally I don't find SwingWorker is ideal so I have my own. Note that an abstract Action implementation is a very useful one, since this is precisely where you need to be doing most of the thread hopping.
