5

I read this excellent article Comparing the Timer Classes in the .NET Framework Class Library and came to the conclusion that anything I could do with Windows.Forms.Timer I can do better with Timers.Timer - and then some.

So the obvious question that comes to mind is: Why is the Windows.Forms Timer offered at all?

Legacy (backward compatibility) support?

Other?

Community
  • 1
  • 1
ih8ie8
  • 944
  • 8
  • 23

6 Answers6

9

The main convenience of the Windows.Forms.Timer is that its events are fired on the UI (Winforms) thread. If your timer events perform UI operations, it may be the simplest alternative (instead of calling Control.Invoke/BeginInvoke or SynchronizationContext.Post/Send inside all of your events).

Ohad Schneider
  • 36,600
  • 15
  • 168
  • 198
  • You are right, it is simpler, but how difficult is it to use `SynchronizingObject` to achieve the same thing? Especially when compared to the "landmines" inherent the simpler timer? – ih8ie8 Oct 19 '12 at 15:15
  • 2
    After reading all answers, I tend to agree with your answer the most: Simplicity of coding for *simple* cases. If however, I want to add some time-consuming non-GUI processing in the future to the event handler... I got a "time bomb" (pun intended :) – ih8ie8 Oct 19 '12 at 15:25
  • @ih8ie8 - using `SynchronizationContext` is very easy: for example, you can cache it in the form's constructor with something like `_context = SynchronizationContext.Current` and then in the event handlers call `_contex.Post/Send(...)`. That said, not having to do that is even simpler :) And of course your comment about long non-GUI work is on the spot. – Ohad Schneider Oct 19 '12 at 20:12
6

The Windows.Forms.Timer events get invoked on the UI thread so you can update the UI from the event handlers directly, which is not normally the case with Timers.Timer (as you would get cross thread access violation exceptions).

And, as @Robert Harvey answered, it also has designer support.

Community
  • 1
  • 1
Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • 2
    The conclusion is: if you need to manipulate the GUI you'd better use this which is *much* simpler, and no need to use invoke. – Alvin Wong Oct 19 '12 at 15:10
  • 1
    @AlvinWong - I would say it is _easier_ to use it for simple scenarios. – Oded Oct 19 '12 at 15:12
  • @AlvinWong You certain *could* do without it and use another timer, but it's just simpler, easier, and requires less boilerplate code. By the same logic, you could always start a background thread in a forms timer if you *don't* want to be in the UI thread, it would just be wasteful. – Servy Oct 19 '12 at 15:12
  • @Oded What if I need to manipulate GUI with data constantly polled from a slow access web page? – ih8ie8 Oct 19 '12 at 15:13
  • @AlvinWong, as the other two stated, one shouldn't always be used over the other, they literally serve two different purposes. – Mike Perrenoud Oct 19 '12 at 15:14
  • @ih8ie8 Then I would *not* use a forms timer. You want the fired event to run in a background thread so you can perform your long running task; you then need to manually marshal to the UI thread to update the result. (That all changes entirely if you have C# 5.0 and async await though.) The forms timer should be used when you want the entire event handler to run in the UI thread. – Servy Oct 19 '12 at 15:15
  • Let's say, for example, when I want to add animations then `Windows.Forms.Timer` should be used? – Alvin Wong Oct 19 '12 at 15:17
  • @Alvin - it depends on what you are doing. If all you are doing is animations, then `Windows.Forms.Timer` is suitable. – Oded Oct 19 '12 at 15:21
6

One of advantage of Windows.Forms is that it run in the same thread of GUI and you do not get cross thread exceptions while accessing Form controls.

Adil
  • 146,340
  • 25
  • 209
  • 204
5

Windows.Forms.Timer has designer support. So it behaves like any other Winforms component (i.e. you can drag it onto a form, it's part of the Controls collection, etc).

Timer events raised by System.Windows.Forms.Timer class are synchronous with respect to the rest of the code in your Windows Forms app. This means that application code that is executing will never be preempted by an instance of this timer class (assuming you don't call Application.DoEvents). Events fired by the Windows.Forms.Timer class are compatible with your Winform controls; you can safely interact with them without having to call Invoke().

The System.Timers.Timer class is a server-based timer that was designed and optimized for use in multithreaded environments. Instances of this timer class can be safely accessed from multiple threads. Although Invoke() is technically required to interact with Winforms, the Timer class does provide a SynchronizingObject property, to which you can attach the Windows form with which you want to safely interact.

More here: http://msdn.microsoft.com/en-us/magazine/cc164015.aspx

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
  • But `Timers.Timer` can be dragged & dropped as well, in the same manner, even handling a SynchronizingObject property for you... So why use `Windows.Forms.Timer` when the framework offers a much superior one? CPU efficiency perhaps? – ih8ie8 Oct 19 '12 at 15:21
  • Among all the differences, I would say that the most important one is that `Systems.Windows.Forms.Timer` is invoked on the same thread as the Winform. It is handy for the things it is useful for, like updating a control on the form at regular intervals. You don't drive the caddy to work if all you need is the pickup truck. – Robert Harvey Oct 19 '12 at 15:24
3

Well I think the answer is that they are two completely different types of timers. The Windows.Forms.Timer is a single-threaded application timer that's well suited for timers existing on the client running application.

A Timer is used to raise an event at user-defined intervals. This Windows timer is designed for a single-threaded environment where UI threads are used to perform processing. It requires that the user code have a UI message pump available and always operate from the same thread, or marshal the call onto another thread.

In contrast the Timers.Timer is a server-based timer that is better suited for Windows services.

The Timer component is a server-based timer, which allows you to specify a recurring interval at which the Elapsed event is raised in your application. You can then handle this event to provide regular processing. For example, suppose you have a critical server that must be kept running 24 hours a day, 7 days a week. You could create a service that uses a Timer to periodically check the server and ensure that the system is up and running. If the system is not responding, the service could attempt to restart the server or notify an administrator.

You can find their documentation and read the excerpts and more from Microsoft.

It's not that one should never be used or always used, the serve two different purposes.

Mike Perrenoud
  • 66,820
  • 29
  • 157
  • 232
0

My belief is that it is for winform designer integration, in that you can drag it onto a form, click it and set its properties in the properties pane.

Frank Thomas
  • 2,434
  • 1
  • 17
  • 28
  • But `Timers.Timer` can be dragged & dropped as well, in the same manner, even handling a `SynchronizingObject` property for you... – ih8ie8 Oct 19 '12 at 15:12