🚀 go-pugleaf

I agree with (and use) Steve's approach.

I typically write functional units as beans.  These beans communicate their
status (including status that would normally update a GUI control such as a
progress bar or status bar) via events.  One central event handler deals with
updates that it listens for, and uses the invokeLater() technique.

For your model updates, I'd route them all throught the same (or similar)
handler, and use invokeLater() there as well.

Take a look at the SwingWorker class at the JavaSoft site  (Articles on its
use are at www.theswingconnection.com).  In terms of you wanting to cancel an
operation - be sure that you properly structure your code so that you can
issue an InterruptedException that will be dealt with appropriately (note
that Thread.interrupt() doesn't really do anything on any of the platforms
thus far, except set a bit that the thread was requested to be interrupted).

Tad Frysinger (TeamB)

"John P. McGrath" wrote:

> I have a Swing desktop application that is currently written without any
> explicit thread creation.  Most of the operations that the program
> performs are quite simple and take little time.  However, there is an
> operation that can be rather lengthy -- on the order of 5 seconds, but
> with complex data it might run up to 20 or 30 seconds.
>
> Currently, the GUI is pretty much dead while this operation is ongoing.
> The fact that it does not respond to user input is a concern, but it is
> not critical since there is little that the user would be allowed to do
> while this is running.  However, it would be useful to give the user the
> option of canceling.
>
> But my primary concern is that the GUI does not _look_ like it is doing
> anything.  To solve this problem, I would like to show a ProgressMeter
> while the operation is performed, but I am not sure of the best way to do
> this.  I am hoping that the solution will also provide the capability of
> canceling the operation.
>
> The ProgressMeter / ProgressMonitor examples I have seen all perform the
> long task in a separate thread, and my application currently does all of
> its work in the event-dispatch thread.  I am concerned that moving this
> work to a separate thread may cause problems.
>
> The application uses a Model-View architecture.  The Swing view
> components are registered as listeners on the model objects, which use
> javax.swing.event.EventListenerList for registering listeners and firing
> events.  All GUI updates are triggered through changes to the model.
>
> The long operation perform extensive modifications of the model, which
> results in many events fired at the Swing view components, which causes
> these components to change their appearance, create some new components
> and remove others, etc.  This works fine, since it is all happening from
> the event-dispatch thread.  But if I were to create a separate thread to
> perform the operation, this would violate the Swing single-thread rule.
>
> Does anyone have any comments or suggestions as how to deal with this?
>
> --
> John P. McGrath
> <mcgrath@enter.net>
> <jpm@nscs.fast.net>