-
Notifications
You must be signed in to change notification settings - Fork 263
State Machine History
A state machine transition’s History property determines which states become active in a destination state's child machines when the transition is taken to its destination or "to" state. If this destination state doesn’t contain a child machine, then History is irrelevant. If the destination state has never been active before, then it has no past history, so History doesn’t matter in this case either: each machine in the destination state enters its start state.
History matters when a state has been active before and contains child machines, because each child machine has an active state. History answers this question: When a state machine transitions back to a state, do you want to restore the last active states for its child machines from the last time this state was active?
History has three possible values:
- None. Past history is ignored. The start state of each active machine contained in the state transitioned to — and of each active machine in any level below it — becomes the active state.
- Shallow. For each active machine contained in the state transitioned to, the active state is the last active state. If these machines have states with active child machines, the active state of each machine is its start state. In other words, use past history only one level down.
- Deep. For every active machine contained in the state transitioned to — and all levels below it — the active state is the last active state.
The states with thick outlines and bold state names were the active states in the child machines the last time the "True" state was active, such as before the last transition was made from "True" to "False" in Level 1. What happens when the transition from "False" to "True" in Level 1 occurs? This depends on the History setting of the transition from "False" to "True":
- None. Past history is ignored, so all active child machines start running in their start states. The current states will be "1" for all child machines in Levels 2 and 3.
- Shallow. History is used only for Level 2, the level below the "True" state in Level 1. In Level 2, the current state will be "2" for machine "A" and "1" for machine "B", since these were the last active states in the child machines at this level. In Level 3, "1" will be the active state in machine "C", since "1" is the start state, and past history is not used at this level.
- Deep. History is used for all levels below the "True" state in Level 1. In Level 2, the current state will be "2" for machine "A" and "1" for machine "B", since these were the last active states in the machines at this level. In Level 3, "2" will be the active state in machine "C", since it was the last active state.
- Circuit Editor Programming Discussion: Learn how ATF handles graphs, and provides editors for kinds of graphs, such as circuits.
- Code Editor Programming Discussion: Shows how to interface third party software to an ATF application: the ActiproSoftware SyntaxEditor.
- Diagram Editor Programming Discussion: Very simply combines components from the CircuitEditor, FsmEditor, and StateChartEditor samples into one application, with the abilities of all three, showing the power of components.
-
DOM Property Editor Programming Discussion: Shows how to use the ATF DOM with an XML Schema to define application data with a large variety of attribute types, whose values can be viewed and edited using the ATF
PropertyEditor
component, using various value editors to view and edit attributes. - DOM Tree Editor Programming Discussion: Shows how to edit DOM data using a tree control and display properties in a variety of value editors.
- File Explorer Programming Discussion: Discusses the ATF File Explorer Sample using list and tree controls with adapters.
- FSM Editor Programming Discussion: Tells you about how the ATF FSM Editor Sample edits simple graphs for state machines, using DOM adapters for contexts and validation.
-
Model Viewer Programming Discussion: Shows how the ATF Model Viewer Sample is written, discussing how ATGI and Collada model data is handled, using rendering components, and using a
DesignControl
as a canvas for rendering. -
Simple DOM Editor Programming Discussion: Programming the ATF Simple DOM Editor Sample, creating a palette, using DOM adapters and contexts, editing application data, and searching
DomNode
s. - Simple DOM Editor WPF Programming Discussion: Programming the ATF Simple DOM Editor WPF Sample, which is similar to ATF Simple DOM Editor Sample, but implemented using ATF's WPF framework.
- Simple DOM No XML Editor Programming Discussion: Programming the ATF Simple DOM No XML Editor Sample, which is very similar to ATF Simple DOM Editor Sample, except that it doesn't use XML for either its data model or persisting application data.
- State Chart Editor Programming Discussion: Shows using ATF graph and other classes to create a statechart editor, using DOM adapters, documents, contexts, and validators.
- Target Manager Programming Discussion: Description of how a target manager is implemented using ATF components to manage target devices, such as PlayStation®Vita or PS3™ consoles. A target manager is used in other tools, such as the StateMachine tool.
- Timeline Editor Programming Discussion: Discusses how to create a fairly full-featured timeline editor using the ATF timeline facilities, such as the timeline renderer and the timeline control and its manipulators.
-
Tree List Control Programming Discussion: Demonstrates using the
TreeListControl
andTreeListItemRenderer
classes to display and edit hierarchical data in a tree view with details in columns. -
Tree List Editor Programming Discussion: Demonstrates how to use the ATF tree controls
TreeListView
and its enhancement,TreeListViewEditor
.TreeListView
usesTreeListViewAdapter
, which adaptsTreeListView
to display data in a tree. - Using Dom Programming Discussion: Shows how to use the various parts of the ATF DOM: an XML Schema, a schema metadata class file generated by DomGen, DOM adapters for the data types, a schema loader, and saving application data to an XML file.
- Home
- Getting Started
- Features & Benefits
- Requirements & Dependencies
- Gallery
- Technology & Samples
- Adoption
- News
- Release Notes
- ATF Community
- Searching Documentation
- Using Documentation
- Videos
- Tutorials
- How To
- Programmer's Guide
- Reference
- Code Samples
- Documentation Files
© 2014-2015, Sony Computer Entertainment America LLC