Re: GUI question
On 5/14/2010 10:34 AM, jason wrote:
[...]
when i use my actionlistener on my button, i expect my progressbar in
GUI1 to update accordingly as updated by a component update call (ie:
component(11).setValue(i)). unforunately it is not doing so.
The "classical" reason for this behavior is that you are
running the progress-making action on the Event Dispatch Thread,
preventing it from responding to changes. Here's the scenario:
1) user does mouse stuff
2) Swing deciphers mouse stuff
2) Swing decides your button has been clicked
3) Swing calls your ActionListener's actionPerformed()
4) your actionPerformed() runs and returns
5) Swing resumes monitoring events
(I'm using "Swing" as shorthand for "Swing, AWT, assorted core
classes, native code, O/S drivers, and miscellaneous whatnot.")
The point is that during (4) above, "Swing" is *not* monitoring
the mouse or the keyboard or anything else: *your* code runs and
monopolizes the EDT until it returns. So if your code tries to
do things to the visible state of a component, nothing (much) will
show up on the screen until *after* your code finishes. Dollars
to doughnuts this is the cause of your difficulty.
The cure is to avoid doing long-winded things on the EDT.
If your ActionListener (or whatever) can do its job quickly and
let any visual changes happen later, fine: Just go ahead and do
it right there in actionPerformed() or in things it calls. But
if the job will take significant time, or if you need the GUI to
remain responsive while the job makes progress, perform the work
on a different thread. Have your ActionListener start a new thread
or send a "work order" to an existing thread, so actionPerformed()
can return immediately while the work progresses in parallel.
All this is described in the on-line tutorial; begin with
<http://java.sun.com/docs/books/tutorial/uiswing/concurrency/index.html>
--
Eric Sosman
esosman@ieee-dot-org.invalid