This is really more of a general .Net Timer object question.
What happens if the code in the Tick method fails to complete before it's invoked again at the next tick? Are ticks queued and looped so that it will still maintain the timeframe?
Printable View
This is really more of a general .Net Timer object question.
What happens if the code in the Tick method fails to complete before it's invoked again at the next tick? Are ticks queued and looped so that it will still maintain the timeframe?
Tick is an event, just like any other. They are raised on the UI thread and the UI thread can only do one thing at a time. If the UI thread is busy when the Tick event is raised then its handlers are not executed until the UI thread becomes available. This is true of all events. Tick is not in any way special in that regard. Now, if the previous Tick event handler is still executing when the next Tick event is raised then that would constitute the UI thread being busy.
I wasn't aware that Timers were part of the UI thread, I thought they had their own seperate one - but thanks for clarifying :).Quote:
Originally Posted by jmcilhinney
I'm starting to wonder whether anyone ever reads the MSDN documentation. From the System.Windows.Forms.Timer class topic:From the System.Timers.Timer class topic:Quote:
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.
Quote:
The server-based Timer is designed for use with worker threads in a multithreaded environment. Server timers can move among threads to handle the raised Elapsed event, resulting in more accuracy than Windows timers in raising the event on time.
...
If you use the Timer with a user-interface element, such as a form or control, assign the form or control that contains the Timer to the SynchronizingObject property, so that the event is marshaled to the user-interface thread.