This repository has been archived by the owner on Jan 5, 2021. It is now read-only.
[Documentation] Behaviour on internally-raised events described #1569
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Fixes #1565. |
BeckmaR
reviewed
Aug 1, 2017
| For the syntax of event declaration, see section ""Events"":#events. | ||
|
|
||
| When a reaction raises an event, the subsequent behaviour of the state machine is highly dependent on the execution scheme, selected by either the "@CycleBased":#statechart_language_cyclebased (default) or the "@EventDriven":#statechart_language_eventdriven annotation. In short: | ||
| * In the _cycle-based execution scheme_, the raised event will be added to the events that are processed by the current run-to-completion step. However, it will only be visible "downstream" in the run cycle, i.e. active states that have not yet been executed can take the event into account. When the run cycle is completed, the event will cease to exist. It can thus not be processed in any subsequent run-to-completion step. |
There was a problem hiding this comment.
"cease to exist" is a bit drastic, maybe "stop to exist", or "not exist anymore"?
There was a problem hiding this comment.
This is a quite usual term. If you don't agree, you are welcome to attribute it to poetic license.
| @@ -916,7 +925,16 @@ p(#fig_region-priorities). | |||
|
|
|||
| p=. Region priorities | |||
|
|
|||
| Not being able to raise an event and process it in "earlier" regions is a restriction you can overcome using variables. The idea is to set a "communication variable" to a certain value in a region that is processed "later". During the next RTC the earlier region could act on the variables value. | |||
| Not being able to raise an event and process it in "earlier" regions is a restriction you can overcome using variables. The idea is to set a "communication variable" to a certain value in a region that is processed "later". During the next RTC the earlier region could act on the variables value. Another option – and in many cases the better on, is to change to the event-driven execution scheme. | |||
There was a problem hiding this comment.
I have the feeling I've read this section three times now. Wouldn't it be more useful to use links and only explain it only once? At the very least, all repetitions have to be maintained.
There was a problem hiding this comment.
I beg to differ. This is the only occurrence of this paragraph in the whole user guide.
andreasmuelder
approved these changes
Aug 1, 2017
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[Documentation] Differentiate Standard and Professional Editions Comp-Documentation