🚀 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