send "subCheckNow" to me, or?

[Garrett Hylltun]

Alex Tweedly wrote:
[snip]
>>
>>> Is it better to use "send" or just use the name of the handler?
>>>
[snip]
>>
> My script compiler doesn't object to it at all (Rev 2.6.1., WinXP). Did 
> you maybe have both options in the script at the same time (in which 
> case the script compiler would complain because there were two handlers 
> with same name) ?

Greetings Alex,

I actually didn't try the second option since I did not know if there 
would be any adverse effects of doing that.  So I only had the first one 
running.

> The second option calls the handler directly - i.e. in the same 
> execution context, so as written it is indeed infinite recursion. Of 
[snip]
>> handler you want to execute is not in the message path.
> 
> Since you were sending to the same handler, it is in the message path, 
> and also you had no delay specified - so it would seem you should never 
> do option 1 in preference to option 2.

Before I try it I have one reservation which I note further down in this 
reply.

> NOTE that a ""delayed send" (such as "send xxx to me in N ticks") is 
> commonly used, because it queues the message, and therefore affects the 
> order of execution. As the docs say,

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 "http://www.411on911drivingschool.com/data/guestid.txt"
     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

[snip]
> 
> but there seems to be no reason to use the "immediate" send to the same 
> handler.

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.

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?

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.

-Garrett