Now you've got me confused. I thought the send parameter was a value in seconds, not a date & time.
You specify the "send" time in a script as a time duration, but the engine converts that to a specific date/time and stores it in the pendingMessages as a specific point in time.
You use send with a parameter of seconds. It goes off into Metacard engine-land and probably sets up an OS timer. It then sits there fat, dumb, and ugly (assuming you're doing nothing else, as in my case) until the time elapses. Then it comes back to your app and says "It's Soup!". It just counts seconds, right? Baring other system delays and blocking operations, it should come back to you in the number of seconds you asked for.
It doesn't really count seconds, it stores the trigger-time as a specific date/time. When that time becomes current, the message fires. If I say "send myHandler to me in 60 seconds" and the time is currently 4:01 PM, the engine adds 60 seconds and stores the trigger time as "4:02 PM" (not in that format, but you get the idea.) The engine checks its pendingMessages list every so often, and when it is 4:02 PM it fires off all the messages that are due, including "myHandler".
All I'm trying to do is to see if the obvserved delay is due to other system resources being used or if a blocking command (possibly "play" for example) is happening or something else I haven't thought of.
"Play" is not supposed to be blocking and subsequent lines of script will execute immediately after the sound has started to play. However, there may be a pause as the sound loads, especially for long sounds or sounds that have to be translated by QuickTime for example.
One other thing to look at is the "send" command itself. As I understand it, the command "send x to me" -- without a time value -- will send the message immediately, before the rest of the handler executes. If a time value is included -- "send x to me in 1 tick" -- the entire handler finishes executing before any message is sent to the queue. Even "send x to me in 0 ticks" will force the rest of the handler to execute before the message gets queued.
Since the only thing you are doing is playing a non-blocking sound, it doesn't seem likely that this distinction will make much difference, but it might. I'd also tend to think that background system tasks, mouse movements, virtual memory disk swapping, whatever, may also cause brief delays. The lag could be caused by something totally outside Revolution's control.
-- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
