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

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

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