Garrett Hylltun wrote:
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.
You need to be careful (i.e. precise) when you say that :-)
send "xxx" to me in N ticks
is kind of like a (delayed) goto - the message is queues, then the code
following the 'send'; statement is executed (so it's not really quite
like a GOTO), and when the handler (and any calling handlers) exits, or
a "wait with messages or other 'send in time' statement is executed)
then the message queue will send the message
On the other hand,
send "xxx" to me
is just not at all like a GOTO. The handler is executed immediately (via
the message passing), but THEN the following code is also executed - so
it's very like a GOSUB, and therefore very, very like just using the
handler name directly; basically the only difference seems to be that
it's less efficient.
So if you were doing simply 'send "xxx" to me' then you would still be
building up a stack of calls; we can argue semantics whether it is
officially called "recursion" or not - but the effect would be that all
of these would have context that needs to be kept simultaneously.
(But your full example only does 'send in time', so your example is OK -
no recursion, no stack of many contexts - but your reasoning above
wasn't :-)
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.
The handler above looks to me like a good case of using 'send in time'.
--
Alex Tweedly http://www.tweedly.net
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 04/07/2006
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
