🚀 go-pugleaf

Tony wrote:

>1. Display and updates of the progress bar are UI operations
>    which must take place on a Swing thread.
>2. Swing thread will not resume until actionPerformed method
>    exits.

The recommended way to do that in Swing is to spin off the methods in a 
background thread.  You would display the progress bar in a modal dialog 
with no "Cancel" button (unless you want the ability to cancel the 
operation) and with the "Close" button in the upper right corner disabled. 
  To update the progress bar, you would post events to the Swing thread.  You can find a tutorial here:

http://java.sun.com/products/jfc/tsc/articles/threads/threads2.html

And some other references on Google:

http://www.google.ca/search?q=swing+background+event+progress+bar

-- 
Kevin Dean [TeamB]
Dolphin Data Development Ltd.
http://www.datadevelopment.com/

NEW WHITEPAPERS
Team Development with JBuilder and Borland Enterprise Server
Securing Borland Enterprise Server
http://www.datadevelopment.com/papers/index.html

Please see Borland's newsgroup guidelines at
http://info.borland.com/newsgroups/guide.html

Tony wrote:

> Sample code that explains my problem:
> 
> startButton.addActionListener(new Action Listener()
> {
>  public void actionPerformed(ActionEvent e)
>  {
>   method1();
>   method2();
>  }
> }
> );
> 
> method1()
> {
> /*
>   I have some long-running operations in this method.
>   Is it true that there is no way to display and
>   update a progress bar in this method?
> */
> }
> 
> method2()
> {
>   /*
>   This method contains operations that must not
>   be performed until method1 is finished
>   */
> 
> }
> 
> My reasoning:
> 
> 1. Display and updates of the progress bar are UI operations
>     which must take place on a Swing thread.
> 2. Swing thread will not resume until actionPerformed method
>     exits.

In addition to Kevin's comments, you may want to have a look at Foxtrot:

http://foxtrot.sourceforge.net/

It may be a better approach than SwingWorker since it uses a synchronous 
model, which is what you are asking for with method2().

David Browne

Thanks a lot for your commends.

Kevin, thank you for the pointer. I have always used the method
you describe in the past, but in my simplified example (actual case
is much more complex) I needed  to avoid immediately returning
from the eventHandler method. I eventually solved the problem by
introducing a useless modal dialog (I used it as a way to re-route
the event dispatch thread to allow me to continue posting events
to the Swing thread without exiting the original event handler).

David, I have not tried using the framework, but by reading the
description it absolutely sounds like a very elegant solution to my
problem and would allow me to avoid using the ugly modal dialog
hack. Thanks a lot for the reference!

I greatly appreciate the help!

Tony.