Open lukashausperger opened 3 years ago
The same here (using the same workaround). Took me some additional time to understand it, maybe you already know this but my explanation is:
SubState
is set to SubSubState
,) but this is not performed recursively. The state of SubState
's initial state SubSubState
is not set.SubSubState
is entered, it get its initial state set the same way SubState
gets it set when it is reentered.
(In my case SubSubState
had three states and remained/was in the state it was left in when SubState
was left. When SubState
was reentered then SubSubState
could also have the middle state.)SubState
is entered because there SubSubState
is unchanged and has the expected initial state.I think it's a bug or at least undesireable because this way SubState
behaves differently between the first and the following times it's entered.
Until now I only used SML and didn't look into the source code, so I have no idea how difficult it would be to fix this. In my opinion fixing it would be an improvement because to me this was unexpected behaviour and took some time to figure out. Also eliminating the workaround would simplify my state machines.
Hey there!
We encountered the following issue:
Expected Behavior
Having a look at the following code snippet, we expect that the
SubSubState
is atLeave3
after trying to enter it for the second time.Actual Behavior
When we try to reenter
SubSubState
inSubState
for the second time (after leaving it), it stucks at the termination stateX
.Steps to Reproduce the Problem
This will output:
So the last assertion fails.
Specifications
Version: master OS: Ubuntu 18.04 Compiler: gcc-10, g++-10
Acutally we found the following workaround which solves this issue: When we change
struct SubState{...}
tothe last assertion does not fail anymore and
SubSubState
is aLeave_3
which is the desired behavior.The question is why isn't it working without this workaround.
Thanks for your support.