aboutsummaryrefslogtreecommitdiffstats
path: root/system/doc/design_principles
diff options
context:
space:
mode:
Diffstat (limited to 'system/doc/design_principles')
-rw-r--r--system/doc/design_principles/statem.xml17
1 files changed, 13 insertions, 4 deletions
diff --git a/system/doc/design_principles/statem.xml b/system/doc/design_principles/statem.xml
index d2a9b23570..69d1e8e9fa 100644
--- a/system/doc/design_principles/statem.xml
+++ b/system/doc/design_principles/statem.xml
@@ -29,7 +29,7 @@
<rev></rev>
<file>statem.xml</file>
</header>
- <marker id="gen_statem behaviour"></marker>
+ <marker id="gen_statem Behaviour"></marker>
<p>
This section is to be read with the
<seealso marker="stdlib:gen_statem"><c>gen_statem(3)</c></seealso>
@@ -199,7 +199,10 @@ handle_event(EventType, EventContent, State, Data) ->
<title>State Enter Calls</title>
<p>
The <c>gen_statem</c> behavior can regardless of callback mode
- automatically call the state function
+ automatically
+ <seealso marker="stdlib:gen_statem#type-state_enter">
+ call the state function
+ </seealso>
with special arguments whenever the state changes
so you can write state entry actions
near the rest of the state transition rules.
@@ -214,8 +217,13 @@ StateName(EventType, EventContent, Data) ->
{next_state, NewStateName, NewData}.</pre>
<p>
Depending on how your state machine is specified,
- this can be a very useful feature, but if you use it
- you will have to handle the state enter call in all states.
+ this can be a very useful feature,
+ but it forces you to handle the state enter calls in all states.
+ See also the
+ <seealso marker="#State Entry Actions">
+ State Entry Actions
+ </seealso>
+ chapter.
</p>
</section>
@@ -964,6 +972,7 @@ do_unlock() ->
<!-- =================================================================== -->
<section>
+ <marker id="State Entry Actions"></marker>
<title>State Entry Actions</title>
<p>
Say you have a state machine specification