send "subCheckNow" to me, or?

J. Landman Gay jacque at
Fri Jul 7 16:32:36 EDT 2006

Garrett Hylltun wrote:

> I've got a delay of 500 milliseconds at the top of the handler.  This 
> was the full handler that I was using:
> on subCheckNow
>   wait for 500 milliseconds with messages  -- < Delay here
>   put field "fCounter" + 1 into field "fCounter"
>   if field "fCounter" > 1800 and field "fAppMode" is "1" then
>     get URL ""
>     put it into field "fResult"
>     put "1" into field "fCounter"
>     if field "fResult" is field "fPrevious" then
>       put "Checked at:  " & short time into field "fStatusLabel"
>     else
>       put field "fResult" - field "fPrevious" into varDiff
>       put varDiff & " new message(s)" into field "fStatusLabel"
>       put field "fResult" into field "fPrevious"
>       set the visible of this stack to true
>       put "4" into field "fAppMode"
>       set the disabled of button "btnRefresh" to true
>       set the disabled of button "btnDismiss" to true
>       set the label of button "btnPause" to "Resume"
>       play audioclip "tick.wav"
>       wait 500 millisec
>       play audioclip "tick.wav"
>       wait 500 millisec
>       play audioclip "tick.wav"
>       wait 500 millisec
>       play audioclip "tick.wav"
>       wait 500 millisec
>       play audioclip "warn1.wav"
>     end if
>   end if
>   if field "fAppMode" is "1" then
>     send "subCheckNow" to me in 1 tick  -- < A 1 tick delay here
>   end if
>   if field "fAppMode" is "3" then
>     close this stack
>   end if
> end subCheckNow

This example is differenet than the short one you posted, and is 
correctly written. For what you are doing, you should continue to use 
"send in <time>" as you do above in the line that sends in 1 tick.

> What I was worried about is the fact that just using the handler name is 
> kind of like doing a "GOSUB" in other languages, and that it expects to 
> return to it's original calling handler when the new handler has 
> completed.  SEND seems like a "GOTO" and doesn't return to the calling 
> handler.  Unfortunately I did not find info in the docs that covered 
> this aspect.

If you use "send <message> in <time>" then the messages do not 
accumulate in a backlog as they would in a recursive call. You can even 
use zero as the time to send, and there will be no delay except for what 
it takes to complete the original handler.

That said, using the handler name to call itself is sometimes done 
without using "send". This creates a recursive handler which does build 
up a backlog in a queue.

> What worries me more is, knowing that just calling the handler by name 
> is like "GOSUB", is a queue being filled up in the engine, just waiting 
> for the "GOSUB" like calls to be returned to their original calling 
> points.  And if they are not returned, what happens to the queue that 
> has built up?  And what will the engine do if that queue gets too large?

Revolution has a recursion limit that prevents a crash if you build up 
too many recursive calls. You'll get an error message about "too much 
recursion" and the scripts will abort. You can even set the 
recursionLimit yourself (see the property in the docs) but you have to 
be careful not to exceed available RAM if you set it too high.

But this particular handler isn't recursive, nor should it be for what 
you are doing.

> I know that in other languages this would likely lead to a crash.
> I think at the moment I'd better stick to using send until I can find 
> out whether the engine will get mucked up by using just the handler name.

This handler is a good example of when to use a "send" loop that isn't 
buried inside a recursive handler call. Not only does it prevent the 
problems you describe, but it yields time to the OS and prevents your 
stack from taking over the CPU and spiking to 100% usage. I have a web 
page about why and how to set up the kind of loop you are already doing, 
which discusses the reasons it's preferable:


Basically I think you've got it right. Recursion in this case wouldn't 
be a good idea. I have used recursive handlers (my Boggle game uses 
them,) but they really only work well when you know ahead of time that 
there is a finite limit on the number of recursions, and that the limit 
is well under the recursionLimit boundary.

Jacqueline Landman Gay         |     jacque at
HyperActive Software           |

More information about the Use-livecode mailing list