🚀 go-pugleaf

Steve wrote:

> 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

"pNichols" <paul@computer-logic.net> wrote in message
news:3fecff09$1@newsgroups.borland.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).

Steve wrote:

> "pNichols" <paul@computer-logic.net> wrote in message
> news:3fecff09$1@newsgroups.borland.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.