Timer Bug.

[theinvisibleGhost]

I think I've found a bug in the timer control.

I've got a class which uses a timer control.
It imports it from System.Windows.Forms

This timer ticks once a second, and then updates a
label which represents a clock on a form, to which the original class
has a reference. (MVC style)

If the user clicks and holds the X button on the form
being updated, the timer stops.
On moving the mouse cursor off of the X button and releasing
the timer continues, however my clock has not moved on.
I think this indicates they are on the same thread or something?

I'd imagine I can get round this by creating another thread,
but this seems wrong, surely a timer by nature should be on another
thread.

Just thought I'd mention it somewhere.
Hope thats ok!
Cheers
Chris.

 

[DalePres]

There is no guarantee that a timer is going to fire in exactly the Interval
property. Many factors can effect that such as other applications or
hardware events on your computer. Perhaps you should set a variable based
on Environment.TickCount to calculate timespans if you need some custom
clock operation or just use DateTime.Now to update your clock label on each
Elapsed event of your timer rather than counting on the interval of the
timer.

HTH

DalePres
MCAD, MCDBA, MCSE

 

[Sean Hederman]

Nope, it's by design, the System.Windows.Forms.Timer is indeed on the
containing forms thread. There is also a System.Threading.Timer which is a
lightweight timer working off the threadpool, and System.Timers.Timer is
designed for use by worker threads.

 

[Guest]

Sean

I have have been having a somewhat similar problem. I have a thread which
runs an db.ExecuteWithResultsAndMessages(...) method asynchronously against a
SQLServer.Database object. I start my timer just before the
db.ExecuteWithResultsAndMessages(...) method. But alas, the timer event (set
to fire every second) only fires after the second thread finishes. And the
SQL statements I tried take so far take at least a minute to complete.
Basically I want my app to echo to the user how many hh:mm:ss have lapsed
since execution commenced.

Much appreciate any helpful pointers!

 

[Sean Hederman]

Which Timer are you using? If the timers on it's own thread use
System.Timers.Timer, otherwise use System.Threading.Timer.

 

[theinvisibleGhost]

Thanks I put in a the System.Timer timer and it worked.
Was following a slightly questionable tutorial off the net which
recommended the forms one.
Still Seems a strange design to me but there we go. Surely most
people that place a timer control are there form aren't going to
realise this?

Cheers
Chris

 

[Sean Hederman]

Thanks I put in a the System.Timer timer and it worked.
Was following a slightly questionable tutorial off the net which
recommended the forms one.
Still Seems a strange design to me but there we go. Surely most
people that place a timer control are there form aren't going to
realise this?

For most form applications the forms timer is perfectly acceptable. For
example, consider if you want you application to check for emails every five
minutes. It doesn' have to be EXACTLY five minutes, it can be close to that.
Since your main UI thread shouldn't be doing massive long-term processing
the timer shouldn't be out by too much. A big advantage of the forms timer
is that you don't add threads (and therefore context switches) to your app,
which makes it a bit more lightweight. Finally, it was apparently decided to
duplicate the behaviour of the VB6 Timer control.

 

[DalePres]

While the System.Timer timer is working for you, keep in mind that there is
still no guarantee that it will fire in one second. Any other process could
cause that to be delayed. Any timer is not a good choice for keeping clock
time. Either the DataTime structure should be used or create your own
functionality counting ticks.

DalePres

 

[theinvisibleGhost]

Cheers. thats actually what I'm doing although I didn't mention
it in the orinal post. The timer produces a tick.
On the tick it updates a DateTime.
However accuracy is not really an issue here, as it's only a test tool
(Was just being picky!).

Did have to do something recently that did have to be accurate
down to about 1ms. involving a timer card dos, and a 1991 Borland c++
compiler and more interrupts than the poor machine had available.
All I can say is never again!