102

what is a difference between System.Windows.Forms.Timer() and System.Windows.Threading.DispatcherTimer() ? In which cases, we should use them? any best practices ?

p.campbell
  • 98,673
  • 67
  • 256
  • 322
paradisonoir
  • 2,892
  • 9
  • 30
  • 41

2 Answers2

117

Windows.Forms.Timer uses the windows forms message loop to process timer events. It should be used when writing timing events that are being used in Windows Forms applications, and you want the timer to fire on the main UI thread.

DispatcherTimer is the WPF timing mechanism. It should be used when you want to handle timing in a similar manner (although this isn't limited to a single thread - each thread has its own dispatcher) and you're using WPF. It fires the event on the same thread as the Dispatcher.

In general, WPF == DispatcherTimer and Windows Forms == Forms.Timer.

That being said, there is also System.Threading.Timer, which is a timer class that fires on a separate thread. This is good for purely numerical timing, where you're not trying to update the UI, etc.

John Cummings
  • 1,949
  • 3
  • 22
  • 38
Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • 1
    Thanks for your prompt response. So this means, whenever I want to have a timer related to UI, I should use DispatcherTimer, and when I want to fire a timer, which I don't want to freeze UL, I should use System.Threading.Timer in a separate thread. The second question is: if I want to use DispatcherTimer, and I want to have a timer not bound to the UI, should I call it in a separated thread by using System.Threading.Timer or still DisptacherTimer? – paradisonoir Jul 10 '09 at 20:14
  • 3
    It depends on what you're trying to do. I rarely use System.Threading.Timer - I usually would stick to Dispatcher Timer, and then do your WORK (which is what could block your UI) in another thread, using something like a BackgroundWorker. The timers really should never block your UI, unless you're doing "too much" work in their event handler. – Reed Copsey Jul 10 '09 at 20:28
  • I am having a problem with DispatcherTimer eating up processor over time. Is there a good way to handle that? – discorax Oct 12 '09 at 17:27
  • Check to see what specifically is eating up the cpu. Are you creating lots of timers, that aren't being stopped? – Reed Copsey Oct 12 '09 at 17:35
  • 3
    Make sure you set the interval property correctly. Don't do this: timer1.Interval = new TimeSpan(1000); // "1000" represents ticks not milliseconds! CPU was super high, until I corrected it with this: timer1.Interval = System.TimeSpan.FromSeconds(1); – Lonnie Best Feb 15 '10 at 00:45
  • I think System.Timers.Timer has better performance than DispathcedrTimer. – NoWar Oct 02 '12 at 11:14
  • In UWP one can also choose to use the ThreadPoolTimer. This should be a very efficient timer, since it does not spin up a new thread if it can reuse one on the thread pool. https://learn.microsoft.com/en-us/uwp/api/windows.system.threading.threadpooltimer – Wim Bokkers Mar 21 '18 at 08:42
5

I've found good article about timers with small examples here: http://www.progware.org/Blog/post/Timers-in-WPF.aspx

As a conclusion:

If DoSomething() manipulates GUI components then with the Timer you need to use: this.Dispatcher.Invoke((Action)delegate { //GUI RELATED CODE HERE} since you cannot access GUI controls from a different thread directly. With DispatcherTimer you do not need to do that.

If DoSomething() performas a time-consuming task, then the GUI will freeze in the case of the DispatcherTimer. In the case of the Timer it won't since the long methos is executed in a different thread

Community
  • 1
  • 1
Seekeer
  • 1,344
  • 2
  • 18
  • 31
  • Ops! what a pity. The link on this answer is broken. This may also help --> https://www.wpf-tutorial.com/misc/dispatchertimer/ – David Mar 11 '21 at 13:51