Re: Could this be done better
On 11/24/2014 11:45 AM, Cecil Westerhof wrote:
Op Monday 24 Nov 2014 15:23 CET schreef Eric Sosman:
[...]
The second problem is (most likely) the cause of the strange
display glitches you refer to: You're updating the display from
a non-EDT thread, and the EDT doesn't "know" right away that things
have changed. There are at least two ways to cure it:
- Inside the TimerTask, use SwingUtilities.invokeLater() to
launch a Runnable that calls updateColour(), so that the call runs
on the EDT instead of on the Timer's thread.
I choose for this solution: was the easiest to do. ;-)
- Use javax.swing.Timer instead of java.util.Timer. The
mechanics are a bit different -- you write an ActionListener
instead of subclassing TimerTask -- but the action listener
automatically runs on the EDT, where it's safe to manipulate
your GUI.
Or is there a reason why did would be better?
(Shrug.) For your purpose I don't see much difference.
But suppose you wanted to add a few more buttons to your GUI:
"Next colour"
"Previous colour"
"Start cycling"
"Stop cycling"
You'll need an ActionListener for the "Next colour" button,
and with javax.swing.Timer you could re-use that exact same
ActionListener for cycling. Essentially, the Timer would fire
the same kind of events the button does, and they'd be handled
by the same chunk of code.
The JavaDoc for javax.swing.Timer mentions another possible
advantage: If you have a *lot* of timed activity in your GUI,
you might wind up creating a *lot* of java.util.Timer threads if
you weren't careful. With javax.swing.Timer that's not an issue;
javax.swing.Timer "multiplexes" all the different events on a
single internal thread. FWIW, I myself have never created so
many Timers (of either kind) that thread multiplicity ever began
to become a problem, but, hey ...
An even more flexible and feature-ridden alternative would be
to use java.util.concurrent.ScheduledThreadPoolExecutor.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM