We can achieve the same behavior (namely that clicking the Quit button quits the state machine, regardless of which state the state machine is in) by grouping states s1, s2 and s3. We could add a transition from each of s1, s2 and s3 however, this seems redundant, and one would also have to remember to add such a transition from every new state that is added in the future. In order to achieve this, we need to create a final state and make it the target of a transition associated with the Quit button's clicked() signal. Sharing Transitions By Grouping StatesĪssume we wanted the user to be able to quit the application at any time by clicking a Quit button. When the state machine enters a top-level final state, the machine will emit the QStateMachine::finished() signal and halt.Īll you need to do to introduce a final state in the graph is create a QFinalState object and use it as the target of one or more transitions. In order for a state machine to be able to finish, it needs to have a top-level final state ( QFinalState object). The state machine defined in the previous section never finishes. QObject ::connect(s3, & QState ::exited, button, & QPushButton ::showMinimized) Ĭustom states can reimplement QAbstractState::onEntry() and QAbstractState::onExit(). QObject ::connect(s3, & QState ::entered, button, & QPushButton ::showMaximized) First, we create the state machine and states:
Simple states code#
The following snippet shows the code needed to create such a state machine. The statechart for this machine is as follows: Initially, the state machine is in state s1.
The state machine is controlled by a single QPushButton when the button is clicked, the machine transitions to another state. To demonstrate the core functionality of the State Machine API, let's look at a small example: A state machine with three states, s1, s2 and s3. Inherits QEvent and holds a clone of an event associated with a QObject Means of returning to a previously active substate QObject-specific transition for Qt events The base class of transitions between QAbstractState objects The base class of states of a QStateMachine These classes are provided by qt for creating event-driven state machines. All the states in a valid configuration of the state machine will have a common ancestor. States can be nested inside of other states, and the current configuration of the state machine consists of the set of states which are currently active. The state graph in the State Machine framework is hierarchical. Qt's event system is used to drive the state machines. The framework integrates tightly with Qt's meta-object system for example, transitions between states can be triggered by signals, and states can be configured to set properties and invoke methods on s. The State Machine framework provides an API and execution model that can be used to effectively embed the elements and semantics of statecharts in Qt applications. With statecharts, this information is easy to express. A key characteristic of event-driven systems (such as Qt applications) is that behavior often depends not only on the last or current event, but also the events that preceded it. This is done by defining the possible states that the system can be in, and how the system can move from one state to another ( transitions between states).
Statecharts provide a graphical way of modeling how a system reacts to stimuli.
The semantics of state machine execution are based on State Chart XML (SCXML). The concepts and notation are based on those from Harel's Statecharts: A visual formalism for complex systems, which is also the basis of UML state diagrams. The State Machine framework provides classes for creating and executing state graphs.
0 kommentar(er)
