Thanks for the replies, everyone. I read in an article that one of the most common Swing mistakes is putting non-GUI work into the event dispatch thread, but it seems like oftentimes the cost of creating a new thread outweighs the benefit of separation, if the work is simple. With the code above, I was trying to figure out how to do a Swing app while performing potentially long procedure, such as contacting a different connected computer.
But for Keith's comments—when would it good to block the Swing thread? Even if I wanted to disable the control that started the action, shouldn't I just use (.setEnabled button false)? I'd think that the GUI should always be able to respond to the user, or else it would seem frozen. I guess it'd be bad with multiple modal dialogs. I think maybe I should just try to avoid those. :) On Jan 27, 4:38 pm, Keith Bennett <keithrbenn...@gmail.com> wrote: > samppi - > > Typical Swing programs create a window with all its components and > event handlers in the main thread, and then launch the event handling > thread implicitly by calling setVisible(true) on the window (usually a > JFrame). I've always done it this way, and have never had a problem. > However, there may be special cases where even the construction of a > window needs to be done on the event handling thread, I don't know. > > By default, *all code* that you define to respond to user events is > called on the event dispatch thread. In my several years experience > working with Swing, use of the SwingWorker technique was very rarely > needed. Of course, if your actions are more time consuming than mine > were, then your experience will be different; but I recommend being > sparing in its use. > > There are complexities associated with *not* blocking the Swing > thread; for example, you'd probably want to disable the control (e.g. > button) that initiated the action to prevent it from being triggered a > second time. In addition, if multiple actions can be occurring > simultaneously, then one has to be sure that their interactions do not > collide. What if two such actions result in the display of a modal > dialog? And you probably wouldn't want the user to be able to close > the window while the button's action is in process. ...and on and > on... > > - Keith --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
