Andreas Huber wrote:
Hi John
<john.wismar <at> autozone.com> writes:
I'm playing with the statechart library, in conjunction with Boost 1.33 and VC 7.1. I'm having trouble using the state history functionality; I can't get it to compile, even taking into account the useful static assertions that ought to be helping me. Can someone suggest what I might be missing?Here's a boiled down sample:
there
are 2 top-level states, StateA and StateB. Event2 transitions between them. When in StateA, Event1 transitions between 2 sub-states, StateA1 and StateA2. When transitioning from StateB to StateA, I want to use StateA's history to determine which of StateA1 and Stae2 become active.
I'm very sorry for the late answer, but I missed your post back in September because it was sent in reply to an unrelated post (Boost Graph Library).
Mick's analysis of the problem is correct. When you make a transition to history then you must specify the *default* *state* that is entered in case the history has never been saved before. The *outer* *state* of the default state must then pass the appropriate has_xxx_history.
Note that this is very much in line with the UML notation. A transition to history always goes to a H disc first and from that H disc you have another arrow to the default state.
Initially I thought it was not quite in line with UML since the boost::statechart implementation allows a different default arrow to be specified for each transition to a H disc, whereas UML only allows a single arrow out of a H disc. But I just realised that afaict UML does not disallow having more than one H disc in a parent state. As such you can have 2 H discs each with a different default state, and boost::statechart supports that.
The state containing the H disc is said to be the one "having history".
From reading the tutorial, references, and sample code, it looks like this should work:
[example snipped]
I checked the docs and I can't find any examples that display the wrong syntax you used. A pointer would be appreciated.
I don't believe your docs are wrong. It is just that it is easy to misread them as it seems natural to expect that you would say: sc::shallow_history<StateA> since you are requesting a transition to one of the sub-states of StateA. Saying: sc::shallow_history<StateA1> just reads a little funny since you may or may not be transitioning to StateA1. The following, while redundant, might actually be easier for people to read: sc::shallow_history<StateA, StateA1> where the first parameter specifies the parent state to which you are performing a history transition, and the second parameter specifies the default state. cheers, mick