Windows.Forms.Timer.Tick

[linuxfedora]

Hi All,

I would like to know do i need to call Timer.Stop inside the Timer
like that?

if Windows.Forms.Timer interval is 500 ms

Timer_Tick(...)
{
Timer.Stop();

Do ...something may longer than the timer, says 1000ms

Timer.Start();
}

or

Timer_Tick(...)
{
Do ...something may longer than the timer, says 1000ms
}


Thanks

 

[Family Tree Mike]

Hi All,

I would like to know do i need to call Timer.Stop inside the Timer
like that?

if Windows.Forms.Timer interval is 500 ms

Timer_Tick(...)
{
Timer.Stop();

Do ...something may longer than the timer, says 1000ms

Timer.Start();
}

or

Timer_Tick(...)
{
Do ...something may longer than the timer, says 1000ms
}


Thanks
.

All anyone can say from here is "maybe". That would be the normal course of
action given your description. A better course of action would be to
identify _why_ you need a timer every 500 ms, for something that takes twice
that amount of time. If you stop the timer, then you are dropping at least
half, but likely many more times when the event should fire.

In other words, either the timer at 500 ms is unresonable, or the processing
time of 1000 ms is unsatisfactory.

Mike

 

[Jeff Johnson]

I would like to know do i need to call Timer.Stop inside the Timer
like that?

Well, take this with a grain of salt, but I seem to recall HEARING (i.e., I
haven't tested it) that timer events are non-re-entrant, meaning that you
will not get another Tick event until you've exited the event handler. It
ought to be a relatively easy thing to test for.

 

[Peter Duniho]

Well, take this with a grain of salt, but I seem to recall HEARING (i.e., I
haven't tested it) that timer events are non-re-entrant, meaning that you
will not get another Tick event until you've exited the event handler. It
ought to be a relatively easy thing to test for.

For System.Forms.Timer, this is completely true. It uses window
messages to deliver the tick, and _no_ window messages can be processed
while the Tick event is being handled, including the one for the next
Tick. (Which is not to say those messages won't pile up...they just
won't get fired while you're working on handling one of them).

For the OP, for me the implication here is that performing timer-based
work in the Tick event handler of a System.Forms.Timer instance is the
wrong thing to do. Blocking the GUI thread for even 500ms isn't great,
but for a full second? That's definitely wrong.

Mike's observation that every 500 ms doing work that takes 1000 ms is a
flawed idea is also accurate, and the OP will need to figure that aspect
out too.

The bottom line: the timer should be assumed to fire every 500 ms, no
matter what. This could be because the work done on the interval is
handed off to a thread pool thread, or it could be because a different,
threaded timer is used instead of System.Forms.Timer. Then, with that
knowledge in hand, the OP can move on to figuring out what the heck he's
actually doing starting 1 second's worth of work every half-second.

Pete

 

[Jeff Johnson]

For System.Forms.Timer

For newsgroup posterity, you meant System.Windows.Forms.Timer, right?

 

[Peter Duniho]

For newsgroup posterity, you meant System.Windows.Forms.Timer, right?

Yup. Hopefully, the person reading that who tries to go find the
System.Forms.Timer class and can't would be able to figure it out. But
thanks for the clarification.

 

[Tim Roberts]

For System.Forms.Timer, this is completely true. It uses window
messages to deliver the tick, and _no_ window messages can be processed
while the Tick event is being handled, including the one for the next
Tick. (Which is not to say those messages won't pile up...they just
won't get fired while you're working on handling one of them).

Actually, they won't pile up. WM_TIMER and WM_PAINT are handled specially.
Rather than going into the real message queue, these two messages just set
flags within the window structure. When the message queue empties,
GetMessage checks these two flags and dispatches a WM_TIMER or WM_PAINT as
appropriate.

 

[Peter Duniho]

Actually, they won't pile up. WM_TIMER and WM_PAINT are handled specially.
Rather than going into the real message queue, these two messages just set
flags within the window structure. When the message queue empties,
GetMessage checks these two flags and dispatches a WM_TIMER or WM_PAINT as
appropriate.

Quite right. Sorry...by "those messages" I had gone on to the more
general issue of what happens when you block the message pump. I did
not mean to mislead...thank you for the clarification.

Pete

 

[Jeff Johnson]

Yup. Hopefully, the person reading that who tries to go find the
System.Forms.Timer class and can't would be able to figure it out. But
thanks for the clarification.

Hopefully it'll prevent a question from EggHead cafe in about 18 months....