Closed jdeantoni closed 3 years ago
any idea ? interest ?
@jdeantoni Thank you for the problem description. You unveiled a bug and a functional hole.
First the transition StateA --always--> StateB is taken before s1 or s2 have the chance to react. This is due to the fact that parent-first-execution is active which should not be the case unless you specify it explicitly. So this is a bug which we will fix with the next bugfix release.
Second you can check for active states in guards. But the final states are not provided as options. These are simply missing in the list of state identifiers. This is the missing functional aspect, We will add those identifiers so that you can specify:
`[ active( StateA.r1._final_) && active (StateA.r2._final_)]`
For our SCXML-statecharts (SCXML domain assigned) we consider to add the done.state.XXX
pattern.
The issue related to the default execution precedence is fixed with release 4.0.4. Thus this issue will be closed.
The remaining topics relating to checking for final states are captutered by the tickets #3217 and #3218. These are scheduled for 4.1 release
I found a potential semantic hole in yakindu for final nodes in orthogonal states.
here is the example:
According to the documentation here: https://www.itemis.com/en/yakindu/state-machine/documentation/user-guide/quick_ref_final_state:
However, it is not clear when the transition from the orthogonal state should be taken ? For now it is taken as soon as the first final node is reached in one of the internal region. It seems strange to me since this behavior is encodable with exit nodes.
Not that in QT, they use the done.state.id stipulated in the scxml norm
Then my question is: how can I wait for all regions to be in a final state like in Qt ? Shouldn't it be the default behavior of the yakindu diagram above ?