>Hi Thomas,
>
>>Hi Fabio,
>>>I'm a lot surprised that nobody is complained of this choice, that evidently is mistaken.
>>
>>It is certainly something to keep in mind. Since _tally can be changed by a lot of things, I follow the rule:
>>If I want to use _tally, I reassign it to something else immediatly after the operation I want to check on. This should isolate me at least from timer problems,
>
>No you are not sure. VFP VM is atomic within a command. If the timer it is asyncronous,
>it can fire the Timer event to the end of a whichever command.
>

>REPLACE FOR ...
>* TIMER CAN START HERE !!
>STORE _tally TO myTally && _TALLY can to be changed here !
>

>
>I check it 3 years, and the only sure way it is to push/pop the _TALLY value within the Timer event.
>
>> but still keeps me in danger from interrupt-like actions (on...). Since the coming bindevent() to windows messages is reported to work in this manner as well, just more to be afraid of.
>
>With this we will see some of all the colors.
>
>Ciao
>Fabio

Fabio,

As an aside, _tally is defined as an unsigned long

_tally = -1
?_Tally
?_tally + 1= 2^32 && TRUE

Concerning the timers:

(1) is you have functions for dynamic.... in a grid, then the timer can fire after each line of the dynamic...() function. But that you knew

(2) if it does, then if the timer.Timer() uses this, this may refer to the grid

That is why my timer events look like

local obj

obj = this

if( Proper(obj.Class) == Proper('QueueProcess') )  && the Timer class, cannot use this

    obj.Enabled  = FALSE && stop timer event

    && process

    obj.Enabled = TRUE	&& restore timer event

else
    && skip a cycle

endif