Doc updates for 2.0.4

Author: mattias-mohlin

art-samples/TrafficLightWeb/webapp/.vscode/launch.json

@@ -0,0 +1,17 @@
+{
+    // Use IntelliSense to learn about possible attributes.
+    // Hover to view descriptions of existing attributes.
+    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
+    "version": "0.2.0",
+    "configurations": [
+        {
+            "type": "node",
+            "request": "launch",
+            "name": "Launch Program",
+            "skipFiles": [
+                "<node_internals>/**"
+            ],
+            "program": "${workspaceFolder}\\app.js"
+        }
+    ]
+}

docs-sources/building/images/build_progress_spinner.png

@@ -40,6 +40,17 @@ If you build a TC and at least one error exists in the TC itself, in prerequisit
 
 Use the setting [`code-rt.build.cancelOnError`](../settings.md#cancel-on-error) to suppress this dialog.
 
+## Cancelling an Ongoing Build
+While a build is in progress you will see a "progress spinner" in the status bar.
+
+![](images/build_progress_spinner.png)
+
+You can cancel the ongoing build by clicking on this progress spinner, and then click the **Cancel** button in the popup that appears:
+
+![](images/cancel_ongoing_build.png)
+
+The build will be terminated immediately with a printout in the **Art Build** output channel: "Build terminated by user." You should expect that the target folder in this case will contain a partial build result. For example, some but not all object files may be present if the build was cancelled while compiling generated code.
+
 ## Building and Running without a TC
 In some cases of rapid prototyping and testing you may want to quickly build and run a capsule without first having to create a TC or a [launch configuration](../running-and-debugging/launch-configurations.md). Then you can click the "Run" link that appears just before any capsule in the Art text editor.
 

docs-sources/building/images/cancel_ongoing_build.png

@@ -58,7 +58,9 @@ tc.threads = [ 'LibraryThread' ];
 If you anyway define physical threads for a library TC they will be ignored by the C++ code generator, and only the logical threads will be considered.
 
 ## Running a Capsule Instance in a Custom Thread
-Capsule instances are connected in a tree structure where the top capsule instance is the root. A capsule instance always lives inside a part of another (container) capsule. The top capsule instance is always run by the main thread, but for all other capsule instances you can choose which thread that should run it.
+Capsule instances are connected in a tree structure where the top capsule instance is the root. A capsule instance always lives inside a part of another (container) capsule. The top capsule instance is always run by the main thread[^1], but for all other capsule instances you can choose which thread that should run it. 
+
+[^1]: It's possible to run the top capsule instance in a custom thread if you [write a custom main function](integrate-with-external-code.md#main-function).
 
 When a new capsule instance is created it will by default be run by the same thread that runs the container capsule instance. This means that by default all capsule instances in the application will be run by the main thread.
 

docs-sources/building/index.md

@@ -70,7 +70,7 @@ capsule Timers {
 If you set a timer with an absolute time that has already passed, or a relative time of 0, the timeout will happen almost immediately. Note the word "almost", because in practise it always takes a little time for the timeout event to be placed in the controller's event queue, and from there be dispatched to the capsule. 
 
 ## Timer Priority
-If you want a timeout event to be processed as quickly as possible you can use a higher than default priority when setting the timer. The last parameter of `informIn()`, `informAt()` and `informEvery()` specifies the priority of the timeout event (by default it's `General` which is the normal priority of an event). In the same way you can lower the priority, if you want the timeout event to be handled at a lower priority.
+If you want a timeout event to be processed as quickly as possible you can use a higher than default priority when setting the timer. The last parameter of `informIn()`, `informAt()` and `informEvery()` specifies the priority of the timeout event (by default it's `General` which is the normal priority of an event). In the same way you can lower the priority, if you want the timeout event to be handled at a lower priority. See [Message Priority](message-communication.md#message-priority) for available priority levels.
 
 The timer set in the example below will timeout immediately and the timeout event will be processed with a higher than normal priority.
 

docs-sources/target-rts/threads.md

@@ -37,6 +37,7 @@ Below is a table that lists all changes made in the TargetRTS since version 8000
 | 8006 | [Static analysis warning reductions](#static-analysis-warning-reductions) <br> [New debugger API "getChildren"](#new-debugger-api-getchildren) |
 | 8007 | [Handle type names containing spaces in encoding/decoding](#handle-type-names-containing-spaces-in-encodingdecoding) |
 | 8008 | [Extend debugger API "getChildren" to obtain active state](#extend-debugger-api-getchildren-to-obtain-active-state) <br> [Long double](#long-double) <br> [RTCONFIG_INFO](#rtconfig_info) <br> [Protocol constructor initializer order](#protocol-constructor-initilizer-ordering) |
+| 8009 | [Simplified qualified names of nested states](#simplified-qualified-names-of-nested-states) |
 
 ### JSON decoder
 A new decoder class [`RTJsonDecoding`](../targetrts-api/class_r_t_json_decoding.html) is now available for decoding messages and data from JSON. JSON produced from data by the JSON Encoder ([`RTJsonEncoding`](../targetrts-api/class_r_t_json_encoding.html)) can be decoded back to (a copy of) the original data.
@@ -99,4 +100,7 @@ The TargetRTS now supports `long double` as other predefined C++ types. The Log
 A [new configuration macro](build.md#rtconfig_info) has been added for controlling if the `config_info` array should be included in `src/RTMain/mainLine.cc`. Previously this array was always included, but not used, which could cause compiler warnings.
 
 ### Protocol constructor initilizer ordering
-The order of initializers in the [Protocol](../targetrts-api/class_r_t_protocol.html) constructor was changed to match the declaration order of the initialized member variables. This avoids a compiler warning.
+The order of initializers in the [Protocol](../targetrts-api/class_r_t_protocol.html) constructor was changed to match the declaration order of the initialized member variables. This avoids a compiler warning.
+
+### Simplified qualified names of nested states
+The function `getStateStr()` in `eventMatches.cc` now returns a simplified representation of nested states that consists of the names of active states separated by a single colon (`:`). Previously, each state name was fully qualified with double colons (`::`) which led to unnecessary complexity when parsing these strings during a debug session.