Losing track of time

[Brian Yennie]

Is it possible that scripts are running at the time when the message is 
meant to be delivered?

Messages won't be delivered in the middle of running handlers unless 
you use an asynchronous call such as "wait with messages".

For example, try this:

global sTime

on mouseUp
   put the seconds into sTime
   send "test" to me in 5 seconds
   repeat with i=1 to 50000
     put i
   end repeat
end mouseUp

on test
   answer (the seconds - sTime)
end test

You'll get something much larger than 5 as your result (unless this 
runs much faster on your machine than mine), because the message 
couldn't be delivered until the handler terminated.

OTOH, if you use "wait with messages" inside the repeat loop, the 
message DOES get delivered on-time.

If you need precise timing and scripts may be running, it may be 
necessary to both:

* Use "wait with messages" in any handlers that could potentially run 
for long enough to disturb your timing

* Re-calculate wait times based on the original "send": this will keep 
the timing from drifting further and further each time. If it's off by 
2 seconds each time, at least it won't become 4 seconds, 6 seconds, etc.

OR... (and this is icky)... if it's really urgent that the timing be 
exact, you might want to send a "pre" message a few seconds before the 
real one which locks out anything that could potentially stop the 
important message from being delivered.

HTH

Brian

> Howard Bornstein wrote:
>> I've got a simple reminder program that takes a number (representing 
>> minutes) and plays a chime when that many minutes is up.
>> The reminder script is:
>> on reminder
>>   global SendID
>>     put fld "TheTime" into timer
>>   send reminder to me in timer*60 seconds    put the result into 
>> sendID
>>   play "chime2.wav"
>>   end reminder
>> The problem is that, for example, if I set the timer to chime every 
>> hour, I am losing about 5 seconds each time I cycle through. 
>> Originally, this was because I had the play "chime2.wav" command 
>> before the send reminder command. So it would play the chime, which 
>> takes several seconds, before resetting the time.
>> But now I've switched the order to the above handler and I'm *still* 
>> getting this lost time per cycle.
>> Is it possible that the play command somehow stops the internal timer 
>> of the send command? This seems highly unlikely but I can't think 
>> what else would be causing this delay, which pushes me further past 
>> the hour as the cycles continue.
>> Any ideas?
>> Regards,
>> Howard Bornstein
>> ____________________
>> D E S I G N  E Q
>> www.designeq.com
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> http://lists.runrev.com/mailman/listinfo/use-revolution
> Try this :
>
> > on idle
> >   global Lasttime
> >   if the seconds = (lasttime+3600) then
> >     add 3600 to Lasttime
> >     play "chime2.wav"
> >   end if
> > end idle
>
> Set up the Lasttime starting value in using a button or so
>
> -- 
> Bien cordialement, Pierre Sahores
>
> Inspection académique de Seine-Saint-Denis
> Serveurs d'applications et SGBDR (Web/PGI)
> Penser et produire l'avantage compétitif
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>