>>>Hi,
>>>
>>>i have found a problem with timer class.
>>>
>>>When a timer is enabled,
>>>- it increment a internal count every Interval time is elapsed,
>>>- decrement the count when Timer event is fired,
>>>- reset the count when Timer.Reset() is call.
>>>
>>>When a long time single command is executed, timer count can to become big.
>>>If i want reset the count, i call Reset method.
>>>
>>>But, this not reset the timer count, and a burst of timer event is fired
>>>
>>>This code repro the problem,
>>>
>>>BUT IT IS NOT DETERMINISTIC
>>>
>>>Changing OS, VFP and Hardware can or cannot show the problem.
>>>
>>>Run this, and click on Try command 2-10 times,
>>>

>>>PUBLIC oform1
>>>
>>>oform1=NEWOBJECT("form1")
>>>oform1.Show
>>>RETURN
>>>
>>>
>>>	**************************************************
>>>*-- Form:         form1 (c:\sviluppo\prove\schede\test timer lock.scx)
>>>*-- ParentClass:  form
>>>*-- BaseClass:    form
>>>*-- Time Stamp:   10/22/03 12:22:00 PM
>>>*
>>>#INCLUDE "c:\sviluppo\g1\include\all.h"
>>>*
>>>DEFINE CLASS form1 AS form
>>>
>>>
>>>	DataSession = 2
>>>	DoCreate = .T.
>>>	Caption = "Form1"
>>>	Name = "FORM1"
>>>
>>>
>>>	ADD OBJECT timer1 AS timer WITH ;
>>>		Top = 11, ;
>>>		Left = 21, ;
>>>		Height = 23, ;
>>>		Width = 23, ;
>>>		Enabled = .F., ;
>>>		Interval = 10, ;
>>>		Name = "Timer1"
>>>
>>>
>>>	ADD OBJECT command1 AS commandbutton WITH ;
>>>		Top = 10, ;
>>>		Left = 66, ;
>>>		Height = 27, ;
>>>		Width = 84, ;
>>>		Caption = "TRY", ;
>>>		Name = "Command1"
>>>
>>>
>>>	PROCEDURE giro
>>>		RETURN 45
>>>	ENDPROC
>>>
>>>
>>>	PROCEDURE Load
>>>		CREATE CURSOR t1 (f1 I)
>>>
>>>		FOR k=1 TO 500000
>>>		   INSERT INTO t1  VALUES (1)
>>>		NEXT
>>>	ENDPROC
>>>
>>>
>>>	PROCEDURE timer1.Timer
>>>            this.reset
>>>	   ? "timer",SECONDS(),this.enabled
>>>	ENDPROC
>>>
>>>
>>>	PROCEDURE command1.Click
>>>		thisform.Cls
>>>		thisform.timer1.reset
>>>		thisform.timer1.enabled = .T.
>>>		? "start update"
>>>		UPDATE t1 SET f1=f1+thisform.giro()
>>>		? "end update"
>>>		thisform.timer1.enabled = .F.
>>>		thisform.timer1.reset
>>>		REPLACE ALL f1 WITH f1+thisform.giro() IN t1
>>>		? "end REPLACE"
>>>		* NOW burst of timer events is fired !!!
>>>	ENDPROC
>>>
>>>
>>>ENDDEFINE
>>>*
>>>*-- EndDefine: form1
>>>**************************************************
>>>

>>>
>>>I run this on:
>>>-XPSP1A
>>>-VFP8SP1
>>>- Compaq notebook P4 2.4Ghz 512MB
>>>
>>Fabio,
>>
>>This isn't a bug. What you're doing is setting the timer interval to a value less than the time slice of the process.
>>
>>Windows is a pre-emptive mult-taskings OS. I wouldn't set the interval property to less than one second. Otherwise, unknown results can occur.
>
>Hmmm... does that mean that Windows' "preemptiveness" is based on time slices and only time slices?
>
>My old mainframe OS 'preemptive multitasking' was based on interrupts, which included timer interrupts. I know that Windows (or at least VFP) doesn't 'do' timer interrupts, but a full second is a long time in a 2+ghz CPU. I would think that there must be something much smaller than a second that is 'safe'. And, frankly, I would think that NO timer interval value should ever produce "unknown results".
>
>cheers

This definition from the Platform SDK should answer your question:

"A multitasking operating system divides the available processor time among the processes or threads that need it. The system is designed for preemptive multitasking; it allocates a processor time slice to each thread it executes. The currently executing thread is suspended when its time slice elapses, allowing another thread to run. When the system switches from one thread to another, it saves the context of the preempted thread and restores the saved context of the next thread in the queue.

The length of the time slice depends on the operating system and the processor. Because each time slice is small (approximately 20 milliseconds), multiple threads appear to be executing at the same time. This is actually the case on multiprocessor systems, where the executable threads are distributed among the available processors. However, you must use caution when using multiple threads in an application, because system performance can decrease if there are too many threads."

The real danger with a timer when set to too small an interval is that the execution of the event may take as long or longer than the alloted time slice.