|
Shifting Dreamscape
Always questioning ...
Join date: 12 Dec 2007
Posts: 266
|
05-27-2008 04:35
Justa simple (I Hope) question on state behavior. Now I know that if I am in State 'A' and have a line of code thats say 'state B;' then the state_exit event will execute for 'A' and the state_entry for 'B'.
What I wanted to know (and can't go online for now to check) is if while in State 'A' I have a line of code that says 'state A;' ... while the state_exit, then state_entry for A execute? And will any listeners started in State 'A' be turned off?
|
|
Dora Gustafson
Registered User
Join date: 13 Mar 2007
Posts: 779
|
05-27-2008 04:58
You can't enter the state you are in from the state you are in. Listeners in one state are all terminated when you enter another state (good way to clean up).
_____________________
From Studio Dora
|
|
Shifting Dreamscape
Always questioning ...
Join date: 12 Dec 2007
Posts: 266
|
05-27-2008 05:38
Thanks Dora ... would have been nice to be able to 'reset' a state with a single line of code.
|
|
Nih Grun
Registered User
Join date: 30 Apr 2008
Posts: 58
|
05-27-2008 06:19
string myoldstate; state a { stuff() { state refresh; // Exit and re-enter current state } state_exit() { myoldstate = "a": } } state refresh { state_entry() { if (myoldstate == "a"  state a; if (myoldstate == "b"  state b; } } I wasn't sure if you can get and store a state, so this would be the long, ugly working version.
|
|
Shifting Dreamscape
Always questioning ...
Join date: 12 Dec 2007
Posts: 266
|
05-27-2008 06:39
Nih .. yep that is basically what I did .. was hoping to avoid the heap overhead of a new state ... but seems to be the only workaorund
|
|
Learjeff Innis
musician & coder
Join date: 27 Nov 2006
Posts: 817
|
05-27-2008 13:07
Yes, unfortunately, "state A" from within state A doesn't cause your state exit and state entry handlers to be called again. I sure wish it did, but it's far too late in the game to make such a change to the language. Such a waste. It would have been simple to make it useful; as it is, it's a no-op. I usually put a dummy state "reA", whose entry handler goes to state A. One wonders whether that's more overhead or less than functions for the state entry and exit handlers, and calling those functions from each point in state A where you want to re-enter the state. Note that these functions have to do more than state entry/exit handlers would have to, since there are side effects to leaving a state, like Dora mentioned. state reA { state_entry() { state a; } }
state A { state_entry() { ... } whatever() { if (...) state reA; } state_exit() {...} }
|