🚀 go-pugleaf

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