update GUI question

[Richard]

Hi all,

I have a question and I think I have a fundamental mis-understanding
with Swing. If anyone could help or give me any pointers I would
appreciate it.

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
seconds. To give the user some feedback I wanted to use a jProgressBar.
I am setting setIndeterminate to true so that the blip just goes back
and forth.

I set off the progress bar when the search happen however the progress
bar does nothing. When the search is done then the program starts the
progress bar. It looks like the processes are happening serially. First
search then start of progress bar. 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.

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

Thanks in advance

Richard

--

 

[opalpa]

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/

 

[Chris Smith]

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
seconds. To give the user some feedback I wanted to use a jProgressBar.
I am setting setIndeterminate to true so that the blip just goes back
and forth.

I set off the progress bar when the search happen however the progress
bar does nothing. When the search is done then the program starts the
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.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Thomas Hawtin]

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

 

[Chris Smith]

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.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Richard]

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



--

 

[Thomas Hawtin]

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?

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