David,
Thinking of it, I think this one will indeed take care of complication 2 that I mentioned. I have used this.enabled=.f. in the past, but apparently it has not become part of my 'automatic coding style'. I'll try to stick to it in the future. Perhaps they should have made it a native property of the timer class.
The first mentioned problem might be tackled by adding the line tmrTimer.enabled=.f. to the other process(es) too. But one oo-programming principle requires that objects are independent and not necesarilly - or even better: not! - aware of each other.
>Peter,
>
>Every time I use a timer to run a process the Timer event looks like:
>
>
>this.Enabled = .f.
>* make method calls to get the work done
>this.Enabled = .t.
>
>
>If it turns out you can get multiple requests queued up while the method is working you can extend the method
>
>
>this.Enabled = .f.
>do while (ARequestInQueue)
> * make method calls to get the work done
>enddo
>this.Enabled = .t.
>
>
>This would guarantee everything in queue gets run without waiting for the next timer tick.
Groet,
Peter de Valença
Constructive frustration is the breeding ground of genius.
If there’s no willingness to moderate for the sake of good debate, then I have no willingness to debate at all.
Let's develop superb standards that will end the holy wars.
"There are three types of people: Alphas and Betas", said the beta decisively.
If you find this message rude or offensive or stupid, please take a step away from the keyboard and try to think calmly about an eventual a possible alternative explanation of my message.
