If you want to signal completion of a state node that you define, you can call postStateCompletion() to post a completion event. This method is inherited from the StateNode class. Writing

postStateCompletion();

erouter->postEvent(EventBase::stateMachineEGID, (size_t)this, EventBase::statusETID);

Why Have Completion Events?

Completion events are produced by state nodes, not their underlying motion commands, sound manager requests, etc. All completion events follow the same format: the generator ID is stateMachineEGID, the type is statusETID, and the source ID is equal to the memory address of the node that is posting the event. Thus a CompletionTrans can be used with any node type. Monitoring the state machine's execution can be achieved by using the Event Logger to display stateMachineEGID events, rather than monitoring a whole collection of generator IDs for the underlying facilities (motions, sounds, etc.) that are being used.

To complement the failure transition, there is a success transition, abbreviated =S=>. Sometimes you want to signal one of two outcomes where neither is a "completion" or an abnormal condition; they're just two possible alternatives, such as an answer to a true/false question. You can use success and failure transitions for this purpose.

DataEvent is a templated class: we have to specify the type of data to transmit in the event. But rather than construct the DataEvent instance directly, it's usually more convenient to use the postStateSignal method, as shown in the example below. It's good programming practice to use enum types rather than constants to denote items from a defined set of choices, so instead of using the values 0, 1, and 2, we will define an enum type called proceedInstruction and use that in our DataEvent. Since the enum type is used both in the node that is sending the signal and the transition that is receiving it, it should be defined outside of either one. Here we define it in the enclosing state node MyBehavior. We use =S=<T>(v)=> as an abbreviation for SignalTrans, where T is the datatype of the signal and v is the signal value to check for.

$nodeclass MyBehavior : VisualRoutinesStateNode {
  enum proceedInstruction {
  turnLeft,
  turnRight,
  straightAhead
  };

  $nodeclass DecideNode : VisualRoutinesStateNode : {
    virtual void doStart() {
      ...
      if ( x < -10 ) {
        postStateSignal<proceedInstruction>(turnLeft);
      return;
      }
      else ...      ...
    }
  }  

  $setupmachine{
    startnode: DecideNode

    startnode =S<proceedInstruction>(turnLeft)=> WalkNode($, 0, 0, M_PI/2, 1, WalkNode::DISP) =C=> startnode

    startnode =S<proceedInstruction>(turnRight)=> WalkNode($, 0, 0, -M_PI/2, 1, WalkNode::DISP) =C=> startnode

    startnode =S<proceedInstruction>(straightAhead)=> WalkNode($, 200, 0, 0, 1, WalkNode::DISPP) =C=> startnode
  }
}

The code above corresponds to the following state machine diagram:

postStateSignal<proceedInstruction>(turnLeft);

erouter->postEvent(DataEvent<proceedInstruction>(turnLeft, EventBase::stateMachineEGID, (size_t)this, EventBase::statusETID));

Receiving the Signal

When a node's doStart method is invoked via a transition firing, the member variable event is set to the event that triggered the transition. (This is also true when the node's doEvent method is invoked.) In the case of a SignalTrans<T> transition invoking the doStart method, event is set to a DataEvent<T>. User code can examine the DataEvent and retrieve the data it contains. A method for doing this, called extractSignal<T>, is provided by the StateNode class, allowing you to write:

virtual void doStart() {
  const proceedInstruction x = extractSignal(event);
  ...
}