On Sunday, December 15, 2002, at 03:18 PM, Troy Rollins wrote:
But the good part is that you can interrupt the cycle by testing a variable state. This particular case may have read -This is a good point.
on cycle
change
if myCustomState is false
send cycle to me in 333 milliseconds
put the result into flashingID
end cycle
If the myCustomState variable (or whatever) is checked to stop a cycle, then saving the ID is not needed. This style might be easier for those new to this.
Modifying the flashing light example off the top of my head:
------------------------------
local flashingIsOn="false"
-- Modify this handler when adapting to other uses
on change
if backgroundColor of me is red then
set backgroundColor of me to green
else
set backgroundColor of me to red
end if
end change
on startFlashing
if not flashingIsOn then -- only one flashing at a time
put true into flashingIsOn
cycle -- no need to "send" the first one
end if
end startFlashing
on cycle
change
if flashingIsOn then send "cycle" to me in .333 seconds
end cycle
on stopFlashing
put false into flashingIsOn
end stopFlashing
--------------------------
In this example, the applicable state is the flashingIsOn local variable and the backgroundColor of the object.
This has the advantage and disadvantage of not actually cancelling the pending messages. This might be handy if the cycle needs to go through a shutdown sequence. If start is modified to restart on busy (as might be important if parameters apply to the state machine), then being able to cancel might be important.
It is possible to keep state in the parameters of one or more cycle handlers, but if you want to stop it you probably need to have at least one part of the state outside, as in these two examples. State in parameters also allows multiple "processes" using the same handlers going on at the same time. (If you mix with other callbacks, such as socket callbacks, you might not be able to have all the info you need in parameters to maintain a full state--global arrays may be needed to keep up with these.)
Dar Scott
_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
