Why use Windows.Forms.Timer at all?

I read this wonderful article Comparing Timer Classes in the .NET Framework Class Library and concluded that everything I can do with Windows.Forms.Timer I can do better with Timers.Timer - and then a few .

So the obvious question that comes to mind is this: why is the Windows.Forms timer suggested at all?

Legacy support (backward compatible)?

Other?

+4
source share
6 answers

The main convenience of Windows.Forms.Timer is that its events are triggered in the user interface thread (Winforms). If your timer events perform user interface operations, this might be the easiest alternative (instead of calling Control.Invoke/BeginInvoke or SynchronizationContext.Post/Send inside all of your events).

+6
source

Windows.Forms.Timer events are triggered in the user interface thread, so you can directly update the user interface from event handlers, which is usually not the case with Timers.Timer (since you will get a cross-thread access violation exception).

And, as @Robert Harvey replied, he also has designer support.

+6
source

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

Timer events raised by the System.Windows.Forms.Timer class are synchronous to the rest of the code in a Windows Forms application. This means that the executable code of the application will never be unloaded by an instance of this timer class (unless you call Application.DoEvents ). Events triggered by the Windows.Forms.Timer class are compatible with your Winform controls; You can safely interact with them without calling Invoke() .

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

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

+4
source

One of the advantages of Windows.Forms is that it runs on the same GUI thread, and you don't get cross-thread exceptions when accessing Form controls.

+4
source

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

A timer is used to summarize an event at user-defined intervals. This Windows timer is designed for a single-threaded environment where user interface threads are used to perform processing. This requires that the user code has a user interface message pump and always runs from one thread or a call marshal to another thread.

Unlike Timers.Timer , a server timer is used, which is better suited for Windows services.

The Timer component is a server-based timer that allows you to specify the recurring interval in which the Elapsed event was raised in your application. You can then process this event to ensure regular processing. For example, suppose you have a critical server that should run 24 hours a day, 7 days a week. You can create a service that uses a timer to periodically check the server and ensure system availability. If the system does not respond, the service may try to restart the server or notify the administrator.

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

Not that you could never use or always use, serve two different purposes.

+3
source

I believe that for integration with the winform developer, you can drag and drop it onto the form, click on it and set its properties in the property area.

0
source

Source: https://habr.com/ru/post/1440808/


All Articles