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 "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
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:
<http://www.hyperactivesw.com/polling.html>
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 | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
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
