Re: How is event:timer handled

[pbl...@odstrategies.org]

I do that myself. That is unless I need more than one thing to happen
from the same timer. You might need a critical section to control and
coordinate events as well. Shutting down the timer sometimes helps
compartmentalize things. When you get into dependencies is when you
might need to add more logic.

So

OF EVENT:Timer
0{Prop:timer} = 0 ! off
DO ThatThing ! do the work and then reset the timer value
0{propr:timer} = NewValue

Sometimes you want the timer period to be more or less than it was. If
you follow the Capesoft NetTalk Email transmission example you queue
up to 20 emails right away then check the queue every so often to see
when the queue is getting low so you can throw a few more messages on
the pile. Just tossing them all in the queue might present a recovery
problem if the process craps out.

I always do like the above so my process can shut down the timer if
there is an error event or I need to change the interval. I don't like
to put a lot of code in the EVENT embed since I may have many things
to do and the code belongs in the routine or procedure.

On 22 Oct 2009 07:21:56 -0400, "Viggo Poulsen" <vp@-remove-vipilon.dk>
wrote:

>Hi
>You can control it like this (in the timer event):
>
>0{prop:timer}=0 !stops the timer
>send, sms and drink coffee :-)
>0{prop:timer}=3000
>
>This way you are sure that no matter how long it takes to handle whatever
>you handle, you will always have 3000 timerticks before the next timerevent.
>Without this method you risk havin a new timerevent right after the first
>one.
---------------------------------------
Paul Blais - Hayes, Virginia