What's the point of Windows.Forms.Timer?

  • Thread starter Thread starter Christoph Nahr
  • Start date Start date
C

Christoph Nahr

Compared with System.Timers.Timer, that is.

Timers.Timer is more precise, has a slightly enhanced functionality,
and is easily synchronized with a Windows Forms application's
foreground thread by setting one (1) property after construction.

Moreover, Windows.Forms.Timer spams your application's message queue
with Tick events, thus increasing the overhead of timer events.
Timers.Timer just calls the event handler directly (after thread
marshalling if necessary).

The MSDN documentation has adopted somewhat of a used car salesman
language and is less than enlightening ("optimized for Windows Forms
applications"!?). But after looking at both classes with Reflector
and seeing the improved application responsiveness with Timers.Timer,
it seems to me that nobody in his right mind would ever want to use
Windows.Forms.Timer.

So can anyone write an apology for Windows.Forms.Timer, or is this
just a legacy class because the responsible team didn't want to leave
this venerable piece of Win16/32 functionality unwrapped?
 
Hi,

This is not an excuse for the Forms timer, just a clarification of some
details :)

The windows forms timer does not actually "spam" the message queue with
timer messages. As with the WM_PAINT message, the WM_TIMER message is not
placed in the message queue in the traditional sense. The WM_TIMER message
is actually a flag which is set and once other messages in the message queue
have been processed is the flag checked and either the windows procedure or
timer function is invoked. So when ever at timer has elapsed, the flag is
set, and if there are other messaged in the queue they are processed before
the timer is dispatched. Obviously this reduces the accuracy of the actual
timer. While the accuracy of the thread based timers is much better, they
require more system resources.

For what it is worth! I would say that the Forms timer is usefull when you
do not require the accuracy and can then save on system resources.
 
The windows forms timer does not actually "spam" the message queue with
timer messages. As with the WM_PAINT message, the WM_TIMER message is not
placed in the message queue in the traditional sense. The WM_TIMER message
is actually a flag which is set and once other messages in the message queue
have been processed is the flag checked and either the windows procedure or
timer function is invoked.
Click to expand...

Thanks for the clarification, so it's not quite as bad as I feared. :)
While the accuracy of the thread based timers is much better, they
require more system resources.
Click to expand...

That's the part I don't understand. Isn't the Windows Forms timer
running in its own thread as well, out of necessity? How can it use
less resources than the Timers timer? Or is it actually just one
global timer for all applications?
 
Hi,

The WM_TIMER messages do not require user mode threads to wait for the event
since the event is dispatched through message handling. While for every
System.Timer uses a completion routine which in turn queues a threadpool
thread to fire the delegate. When the synchronization object is set, the
thread from the threadpool firing the delegate uses BeginInvoke to fire the
delegate, which marshals the call to the UI thread context. Obviously the
framework is shielding us from all this complexity, however under the covers
the WM_TIMER is much more lightweight, but less accurate. One observation
here, is that since marshalling the event from the threadpool thread to the
UI thread actually uses the message queue long running message handlers can
significantly impact the accuracy of a synchronized System.Timer.

Hope this helps
 
The WM_TIMER messages do not require user mode threads to wait for the event
since the event is dispatched through message handling.
Click to expand...

Sorry to keep nagging, but who _creates_ this event in the first
place? Doesn't there have to be a separate timer thread running
_somewhere_ in order to create WM_TIMER messages?
One observation
here, is that since marshalling the event from the threadpool thread to the
UI thread actually uses the message queue long running message handlers can
significantly impact the accuracy of a synchronized System.Timer.
Click to expand...

Very interesting, I'll keep that in mind.

Speaking of which, I noticed that calling Sleep on a GUI thread seems
to enable the _same_ thread to execute other queued messages. Is .NET
duplicating the thread context behind the scenes in this case?

(Does anyone cover the interplay of Windows Forms and multithreading
in detail? The books I have only cover one or the other, not both.)
 
Sorry to keep nagging, but who _creates_ this event in the first
place? Doesn't there have to be a separate timer thread running
_somewhere_ in order to create WM_TIMER messages?
Click to expand...

System.Windows.Forms.Timer is backed by the Win32 API SetTimer. I highly
recommend reading the documentation for SetTimer and KillTimer. Note that
Windows handles the creation of the message in this case, and there is a
resource issue here since each timer creates a little bit more overhead in the
system.

The System.Timers.Timer class on the other hand is backed by the
CreateWaitableTimer. The code they use is far more complex and is completely
dependent on background threads, the thread pool, and possibly marshalling the
call onto the UI thread as pointed out earlier depending on your application.
 
System.Windows.Forms.Timer is backed by the Win32 API SetTimer. I highly
recommend reading the documentation for SetTimer and KillTimer. Note that
Windows handles the creation of the message in this case, and there is a
resource issue here since each timer creates a little bit more overhead in the
system.
Click to expand...

Hmm. Thanks for the info but I don't see how you got that out of the
rather sparse Platform SDK documentation... again, is there any
literature where this issue is described in any kind of detail?
The System.Timers.Timer class on the other hand is backed by the
CreateWaitableTimer. The code they use is far more complex and is completely
dependent on background threads, the thread pool, and possibly marshalling the
call onto the UI thread as pointed out earlier depending on your application.
Click to expand...

Well, if you say the code is far more complex I guess I'll have to
believe you because I still don't see the reason!
 
Hi Christoph,

Chris and Justin had given many valuable information about System Timer
class and the Winform Timer class. It's greate.
I happen to know there is an article in MSDN Magazine which also did a
comparsion among the 3 Timer classes in .NET Framework. You may read the
article to see if it give you some ideas on this topic.
<Comparing the Timer Classes in the .NET Framework Class Library>
http://msdn.microsoft.com/msdnmag/issues/04/02/TimersinNET/default.aspx

For anything unclear on this issue, please feel free to reply this thread.
Thanks!

Best regards,

Ying-Shen Yu [MSFT]
Microsoft community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.
 
Hi,

Justin is correct, using the Win32 APIs for waitable timers is much more
complex than handling a WM_TIMER message, however the .NET Frameword
abstracts this complexity and exposes it as a simple consistent interface.
To get the nitty gritty I would suggest that you study the underlying Win32
APIs. I usually find that some of my older references contain much more
detail than the more modern stuff.

If the details interest you, my recommendation is Advanced Windows by
Jeffery Richter, I have an older edition, but I believe the newer 3rd
edition would be as good if not better.
http://www.amazon.com/exec/obidos/t...103-7267787-4727847?v=glance&s=books&n=507846
or
http://tinyurl.com/2mwds

Hope this helps
 
Back
Top