"Jason Cavett" <jason.cav...@gmail.com> wrote in message
news:1175706250.562815.18120@n76g2000hsh.googlegroups.com...
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();
--
Mike W- Hide quoted text -
- Show quoted text -
Ah, good point. I've been using MVC throughout my application, it
would only make sense to use it here. Thank you.