Board index » jbuilder » GUI Responsiveness Problem

2003-12-25 08:33:20 AM
jbuilder19
Imagine a GUI control that starts a long-running process from its action
event. Since the event handler executes on the event-handling thread, the
GUI is frozen while the process completes. Often this is exactly what we
want (e.g., refreshing a query; there's nothing for the user to do until the
refresh is complete). JButton handles this nicely by depressing and changing
the cursor _before_ the action event handler is called so that the user
knows the application isn't frozen. But JComboBox leaves its picklist
extended and appears frozen to the user until the event handler exits.
What I'd like to be able to do is for the JComboBox to get ahold of itself,
but still block on the event-handling thread after that. Any ideas?
I came up with a really hideous hack that I'm not happy with: In the action
event handler, create a SwingWorker with an empty construct() method and the
long-running process called from the finished() method (forcing it on to the
event-dispatching thread). The start() method is called just before the
event handler exits. This gives the GUI enough time to retract the picklist.
However this is a kludge because it's timing dependent. It also doesn't work
if you put any other GUI code in the event handler (e.g., setting the wait
cursor) unless you add a delay timer to the construct method. There's gotta
be an easier way to do something so basic.
Any ideas greatly appreciated. Thx.
-Steve
 

Steve wrote:
and Listener events performance probems that you might want to take a look
at. I think it could address some of your issues.
www.sys-con.com Look at the bottom article, Swing,Threads, and events
 

"pNichols" < XXXX@XXXXX.COM >wrote in message
albeit with more example code. It did nudge me to look at the source for
SwingWorker, though. Since the finished() routine is run by invokeLater, it
should be attached to the end of the queue. Since this doesn't always have
the effect I intended, it strengthens my suspicion that this was just lack
of forsight in the way that JComboBox was written (i.e., the list should be
retracted before it calls the action event handler).
 

{smallsort}

Steve wrote:
Swing. I constantly monitor my programs to see how many iterations they
make through an ActionEvent or WindowListener which will fire not only on
these events but any subsequent events within the same inner class. I think
Javasoft DEFINITELY needs to revisit the way they implement these Listener
classes.