"Repeat while the mouseClick is false" makes program hang

[jacque]

Hi Sri. The idea is to avoid waiting inside a repeat loop. To do that, you just toggle what the mouseup does depending on how long it has been since the last mouseup and whether the current state is "waiting" or not. You don't need a repeat at all. Here's the idea:

Code: Select all

local sWaiting, sTime -- script local variables

on programStart
  playAudio -- the program initiates the sequence
  put the seconds into sTime -- note current time
  put true into sWaiting -- set state
end programStart

on mouseUp
  -- if sWaiting is empty or false, we aren't waiting for a response so just bail out:
  if sWaiting is not true then exit mouseup
  -- at this point we're expecting a response, see what the time is:
  if the seconds - sTime > 10 then -- time limit was reached
     repeatAudio -- repeat the phrase with emphasis
     put the seconds into sTime -- reset timer; sWaiting is still in effect
  else -- the click occured within 10 secs:
    put false into sWaiting -- turn off waiting
    processTheClick -- do necessary things
  end if
end mouseUp

Where it says "do necessary things" you will want to call "programStart" again, or whatever sets off the next audio file and resets the script locals.

BTW, true and false are both constants and don't need to be quoted.

[sritcp]

Hi Jacque:

We want to repeat the sentence if there was no click for 10 sec.
Your code checks for the lapse of time under mouseUp handler; i.e., only after the user clicks, it measures if over 10 seconds had elapsed since the first audio.
Since we want to repeat the audio in the absence of a click, shouldn't the time check be outside the mouseUp handler?

Regards,
Sri.

[jacque]

Yes, you're quite right. Somewhere in the discussion I lost track of your original goal. This is where the "send" command comes into play. The script repeatedly polls for the time by sending a time check at regular intervals. The advantage of this method is that it does not block the CPU or halt any background processes that the OS or other apps may be doing. If you were to use "wait with messages" in a repeat loop, it would run full-tilt at an uncontrolled rate; Mark's tests showed it locked up 90% of the CPU. With a "send" command there should be no impact at all because you can keep the polling down to a more reasonable rate of once or twice a second.

Code: Select all

constant tMilSecs = 1000 -- one second; reduce for more precision
local sWaiting, sTime -- script local variables

on programStart
  playAudio -- the program initiates the sequence
  put the seconds into sTime -- note current time
  put true into sWaiting -- set state
  send "checkTime" to me in tMilSecs milliseconds
end programStart

on checkTime -- poll for elapsed time
  if sWaiting is not true then exit checkTime
  if the seconds - sTime > 10 then -- time limit was reached
    repeatAudio -- repeat the phrase with emphasis
    put the seconds into sTime -- reset timer; sWaiting is still in effect
  end if
  send "checkTime" to me in tMilSecs milliseconds -- poll again later
end checkTime

on mouseUp
  if sWaiting is true then
    put false into sWaiting -- turn off waiting
    processTheClick -- do necessary things
  end if
end mouseUp

Mark was correct that this method isn't as easy to understand for newcomers, but I think the advantages outweigh the slight learning curve. It's the recommended way to do any type of polling because you can control the impact on the rest of the computer.

If a loop is going to take only a second or so, or you need to measure a time lapse in the smallest possible increment, it probably doesn't matter; "wait with messages" is fine because the difference won't be discernable. But for longer intervals, this method is more efficient and plays nice with others.

[sritcp]

Yes, I think I'll use the checkTime recursion.
So,
"repeat" holds up system resources (even with "wait 500 milliseconds with messages"), but
"send in 500 milliseconds" doesn't.
Good to know.

Thanks,
Sri.

[jacque]

So, "repeat" holds up system resources (even with "wait 500 milliseconds with messages"), but
"send in 500 milliseconds" doesn't.

Not exactly, it depends on balance. For example, this will lock up everything until the loop is finished:

Code: Select all

repeat with x = 1 to someHugeNumber
  add 1 to x
end repeat

If a loop is going to run a long time, you should yield time to the OS and other processes:

Code: Select all

repeat with x = 1 to someHugeNumber
  add 1 to x
  wait 1 with messages
end repeat

This will slow down the handler because there's a wait inserted, but it plays nice with other processes. The loop itself is very short and will run very fast (it only has one operation to do.) The balance between the loop activity and background processes is sort of equal. If the wait were extended to 500 milliseconds, the loop would yield more time than it takes to do its processing. The handler would be slow and inefficient. And if any other event happens during the loop (like a mouseclick) that doesn't occur exactly during the "wait" statement, that event will either be missed or postponed. The engine will only check for user and system events during the wait. A short loop like this one with half the time dedicated to a "wait" will probably catch most events, but may not catch all.

If the loop takes a long time to execute and the wait is short, the balance changes:

Code: Select all

repeat with x = 1 to someHugeNumber
  doSomethingReallyTimeConsuming
  wait 1 with messages 
  doMoreTimeConsumingStuff
end repeat

In this case the handler blocks everything while the loop runs and yields only a tiny sliver to the OS. Background processes will slow down or stop and LiveCode will use almost all the CPU. Most user events will be missed or postponed because it's unlikely they will occur during the precise moment when the wait is happening. Yielding a tiny slice is better than not yielding at all, but the balance is off. Sometimes you have no choice, but when possible it's better to avoid this.

If a script needs to do only occasional polling, like checking a timer, then pulling it out of the repeat loop entirely is a better way to go. Instead of relying on a "wait" to catch events, the script instead allows unlimited events in between calls to the timer-checking handler. Basically the balance is reversed -- more time is spent with no handlers running at all (freeing up all system resources,) and only momentary checks are done on a schedule.

That may be more than you wanted to know.

[sritcp]

....if any other event happens during the loop (like a mouseclick) that doesn't occur exactly during the "wait" statement, that event will either be missed or postponed.
.............
Most user events will be missed or postponed because it's unlikely they will occur during the precise moment when the wait is happening.

This is disturbing! I can understand a mouseClick being 'postponed', but do you mean to say that if a mouseClick occurs exactly when another handler or process (not necessarily "repeat") is running, it will not even register (to be processed later)? If so, would it mean that it is best to make our handlers short and bite-sized rather than have them perform a long series of tasks?

That may be more than you wanted to know.

Not at all. Thanks for your time.

Regards,
Sri

[jacque]

All events are queued, with one exception, so you won't miss anything if they occur when another handler is running. The one exception is repeat loops. I remember when the behavior was changed, there was a discussion about efficiency (this was many years ago before RR acquired the engine.) The upshoot was that efficiency won out, and during repeats, the state of the mouse would only be checked at the exact moment of idle and previous mouse changes that occured while the loop was running would not queue.

Handlers won't miss any events otherwise, and non-mouse events (I'm pretty sure) will still queue, though they may not trigger until the handler is done.

[sritcp]

Good information.

Thanks, Jacque!

Sri.