Updating GUI Components From A Thread

[Jason Cavett]

I've been reading up on how to update a GUI component from a Thread
and, as far as I can tell, I need to have my Thread update the GUI
component (JLabel in this case) by using a
SwingUtilities.invokeLater(Runnable) call inside the worker thread at
various points. An example is shown below (I realize there are
problems with this code - I'm just trying to demonstrate an
understanding):

public void run() {
while (true) {
try {
// do some stuff and set the boolean variable
"failed" based on the work done
SwingUtilities.invokeLater(statusUpdate);
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}

return;
}

In the constructor of the worker class, I defined statusUpdate like
this (status is a class that extends JLabel):

statusUpdate = new Runnable() {
public void run() {
status.updateErrorStatus(failed);
}
};


What is confusing to me is that the class that is doing the
"work" (the thread class) needs a reference to a GUI component (or
possibly more than one GUI component if there are multiple views that
need updating based on this thread). Maybe I'm getting myself
confused, but that seems like poor design. Am I thinking about this
the wrong way? Is there something I'm not understanding?

Thanks for any explanation.

 

[visionset]

I've been reading up on how to update a GUI component from a Thread
and, as far as I can tell, I need to have my Thread update the GUI
component (JLabel in this case) by using a
SwingUtilities.invokeLater(Runnable) call inside the worker thread at
various points. An example is shown below (I realize there are
problems with this code - I'm just trying to demonstrate an
understanding):

public void run() {
while (true) {
try {
// do some stuff and set the boolean variable
"failed" based on the work done
SwingUtilities.invokeLater(statusUpdate);
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}

return;
}

In the constructor of the worker class, I defined statusUpdate like
this (status is a class that extends JLabel):

statusUpdate = new Runnable() {
public void run() {
status.updateErrorStatus(failed);
}
};


What is confusing to me is that the class that is doing the
"work" (the thread class) needs a reference to a GUI component (or
possibly more than one GUI component if there are multiple views that
need updating based on this thread). Maybe I'm getting myself
confused, but that seems like poor design. Am I thinking about this
the wrong way? Is there something I'm not understanding?

Thanks for any explanation.

If you use an MVC (Observer Pattern) design then your worker thread updates
the model and the view has listeners on the model to enable it to update.
These listeners are usually a mixture of your own implementation and
internal Swing library listeners. In the listeners you write you stick your
call to invokeLater unless you are certain it's the event thread firing the
event, though you can check this with
SwingUtilities.isEventDispatchThread();

 

[Jason Cavett]

If you use an MVC (Observer Pattern) design then your worker thread updates
the model and the view has listeners on the model to enable it to update.
These listeners are usually a mixture of your own implementation and
internal Swing library listeners. In the listeners you write you stick your
call to invokeLater unless you are certain it's the event thread firing the
event, though you can check this with
SwingUtilities.isEventDispatchThread();

Ah, good point. I've been using MVC throughout my application, it
would only make sense to use it here. Thank you.

 

[Tom Hawtin]

If you use an MVC (Observer Pattern) design then your worker thread updates
the model and the view has listeners on the model to enable it to update.
These listeners are usually a mixture of your own implementation and
internal Swing library listeners. In the listeners you write you stick your
call to invokeLater unless you are certain it's the event thread firing the
event, though you can check this with
SwingUtilities.isEventDispatchThread();

I suggest only updating the model on the EDT. Multithreading is much
easier if you do almost everything single threaded. Keep the interface
between threads as narrow and as clear as possible. I point to Swing
text as an example where threads and listeners lead to a completely
broken system.

Tom Hawtin

 

[Daniel Pitts]

Ah, good point. I've been using MVC throughout my application, it
would only make sense to use it here. Thank you.

Actually, this is a common mistake...
SwingUtilities.invokeLater was wraps a public method elsewhere, and
that other method should be used.
java.awt.EventQueue.invokeLater

 

[Brandon McCombs]

If you use an MVC (Observer Pattern) design then your worker thread updates
the model and the view has listeners on the model to enable it to update.
These listeners are usually a mixture of your own implementation and
internal Swing library listeners. In the listeners you write you stick your
call to invokeLater unless you are certain it's the event thread firing the
event, though you can check this with
SwingUtilities.isEventDispatchThread();

If you think my idea sounds good I'd wait until someone else chimes in
before you do it in case it isn't the best/right way to do it.

What I did for something like this was I created an interface that
contains methods that I later defined in my JPanels. I have 3 JPanels
with each one being a tab on a JTabbedPane. Since each JPanel had to
work with results from the same thread in different ways the interface
methods let me define the specific way each JPanel had to update itself.

I made the thread's constructor accept a class of the same type as the
interface and each JPanel implemented that interface. I'd instantiate
the thread and pass in the JPanel as the argument. I'd then start the
thread. When the thread got done with its results it would call the
updateGUI() method from the interface for the particular JPanel that
spawned the thread. The JPanel then received those results and processed
them in whatever way was appropriate. I'd use the following to make the
updateGUI() call (results is a vector and component is a JPanel that
implements my AsyncSearch interface):

SwingUtilities.invokeLater(new Runnable() {
public void run() {
component.updateGUI(results);
}
});


I hope that helps (especially if someone else says it sounds like a good
way of doing it. By the way, the JPanels would update their specific
data model class (such as a ListModel) within their updateGUI() methods
so that sort of falls in line with Mike W's advice of having the thread
update the model based on MVC (but not exactly the same).


Brandon