Samppi -
On Jan 28, 12:53 pm, samppi wrote:
> 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 s
Samppi -
On Jan 28, 12:53 pm, samppi wrote:
> 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 s
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,
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, t
> I read
> somewhere that I should do those things only in the "event dispatch
> thread", and that SwingUtilities.invokeLater(Runnable) would make that
> work. But I'm not sure if I get it yet; why would I need to do that?
The GUI runs in its own thread (the event thread). If you tried to
update
Thanks for the response. Yeah, I used SwingWorker just for education's
sake. I'm just trying to figure out the best practices to do for
Clojure/Swing in the future. The last question was about something I
read on one of Sun's Swing tutorials--the text-sampler-gui function
calls a bunch of Swing co
samppi -
I don't suggest using SwingWorker for this unless you just want to
practice using it for education's sake. The calculation time is
effectively zero in an application like this where actions are user-
triggered, so using SwingWorker is a case of unnecessary and premature
optimization...a
I'm trying to learn Swing, so I'm writing the most robust Celsius
converter app that I can. I've separated the conversion work into a
separate SwingWorker thread, so this requires Java 6. Does anyone have
any suggestions?
(ns org.sample.play-with-swing.multithreaded-celsius-converter
(:impo