Board index » jbuilder » GUI Responsiveness Problem

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
 
 

Re:GUI Responsiveness Problem

Steve wrote:
Quote
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
there was a good article this month In Java Developer's Journal about Swing
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
 

Re:GUI Responsiveness Problem

"pNichols" < XXXX@XXXXX.COM >wrote in message
Quote
there was a good article this month In Java Developer's Journal about
Swing
and Listener events performance probems that you might want to take a look
at. I think it could address some of your issues.
Thanks for the tip. It covers about the same ground as the Sun tutorial,
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}

Re:GUI Responsiveness Problem

Steve wrote:
Quote
"pNichols" < XXXX@XXXXX.COM >wrote in message
news:3fecff09$ XXXX@XXXXX.COM ...
>there was a good article this month In Java Developer's Journal about
Swing
>and Listener events performance probems that you might want to take a
>look at. I think it could address some of your issues.

Thanks for the tip. It covers about the same ground as the Sun tutorial,
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).
There are a myriad of problems with Listeners and Event classes in Java
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.