The following document may clairfy use of Swing progress bars:
http://java.sun.com/docs/books/tutorial/uiswing/components/progress.html
http://www.geocities.com/opalpaweb/
> I have written a search program that looks for particular files and
> then displays them in a jtable. Now this search can take up to 30
[quoted text clipped - 6 lines]
> progress bar. It looks like the processes are happening serially. First
> search then start of progress bar.
Yes. All GUI updates happen from the AWT event dispatch thread. That
is the same thread that is used to call your event handlers. If you
perform the search directly in an event handler (or anything called from
it), the progress bar won't be updated at the same time. Instead, you
should spawn a new thread from the event handler to perform the long
task.
> However I set the progress bar off
> before the search starts. I have tried to start the progress bar off on
> another thread, thinking it is a thread issue but this does not work.
You tried to move the wrong thing. GUI updates involve posting and
handling events. Regardless of what thread you use to call Swing API
methods, events and repaints are always performed in the AWT event
dispatch thread the next time it's available, and there's nothing you
can do to change that.
It's actually incorrect to call Swing APIs from outside of the event
dispatch thread, anyway. Swing is not thread-safe, and using it from
outside the event dispatch thread results in a race condition and can
cause unpredictable lockups, crashes, or other failures in your code.
So move the long-running task, not the progress bar... and use
EventQueue.invokeLater when you need to update GUI stuff at the end of
the other thread.

Signature
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
> How can I get Swing to update the progress bar while the search is
> going on? I havent given much info on my program here because it is
> quite complicated. If this is a hindrance then any tips would be
> appreciated
SwingWorker is a convenient way of covering up the details. I'm not
particularly keen on this sort of design, but it's a start. It is also
planned to be part of Java SE 6.
https://swingworker.dev.java.net/
http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html#SwingWorker
Tom Hawtin

Signature
Unemployed English Java programmer
http://jroller.com/page/tackline/
Chris Smith - 06 Jan 2006 15:43 GMT
> SwingWorker is a convenient way of covering up the details. I'm not
> particularly keen on this sort of design, but it's a start. It is also
> planned to be part of Java SE 6.
I must be missing something. Everyone seems so terribly interested in
SwingWorker... but I still can't figure out what it does that's of any
use! Are people just that afraid of using the Thread and EventQueue
classes by themselves? Anyone want to provide an example of something
that's easier with SwingWorker than with a vanilla implementation?
Of course, with Sun's new-found (as in, the latter two-thirds of Java's
life) attitude of "adding a new API can solve any problem", it's not
surprising that they are adding SwingWorker to the standard API. I'd
just like to find out if there's some real reason to use it that I just
haven't seen.

Signature
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
Thomas Hawtin - 07 Jan 2006 22:49 GMT
>>SwingWorker is a convenient way of covering up the details. I'm not
>>particularly keen on this sort of design, but it's a start. It is also
[quoted text clipped - 5 lines]
> classes by themselves? Anyone want to provide an example of something
> that's easier with SwingWorker than with a vanilla implementation?
It's mostly about removing barriers to entry. It doesn't do a great
deal, but user code seems more straightforward to me.
SwingWorker also buys you a few nice things: collects multiple products
together (can be important), thread pooling (don't think this is often a
problem) and firing progress events back on the EDT (you would have
though they could have added direct support of
JProgressBar/BoundedRangeModel.
For more advanced coding, I'd prefer not to have the whole thing stuck
together in a ball from the start.
Tom Hawtin

Signature
Unemployed English Java programmer
http://jroller.com/page/tackline/
Thanks a lot for all your help guys. I will look into fixing this at
the weekend. Thanks also for the SwingWorker pointer. I keep saying to
myself that I should look at the Mustang site in more detail.
Thanks again
Richard