What is the difference between RunSate and ThisContext?

[Xiaoyiyi]

Hi:

   I am a newer for Teststand .I am not clear for thedifference between the "RunState" and "ThisContext".

Can someone can explain it? Any help appreciated!

[~jiggawax~]

According to the TestStand help:

The RunState property object contains properties that describe the state of execution in the sequence invocation.

ThisContext- Reference to the current sequence context. You usually use this property to pass the entire sequence context as an argument to another sequence or a step module.

A sequence context is an object in the TestStand API that represents the execution state of a sequence. For each active sequence, TestStand maintains a sequence context you can use to access all the objects, variables, and properties that relate to the execution of the sequence.

The way that I understand it is that RunState is a property with subproperties and ThisContext is a reference.  RunState will always contain information about the current sequence you call it from.  ThisContext can be passed to other threads and updated from those threads or submodules.

Hope this helps,

[bienieck]

What is the difference between the ThisContext (Sequence Context) and the RunState? That is an excellent question. The concept of the RunState is very confusing or even mysterious. There are a couple of reasons why it isn't obvious:

1. Documentation: The way the TestStand help describes the Sequence Context and the RunState leaves you with an impression that it is the same thing (and it kind of is). The Sequence Context is "an object in the TestStand API that represents the execution state of a sequence," and the RunState "contains properties that describe the current state of execution." So both contain information about the execution state.
2. Data duplication: The RunState is an almost perfect subset of the Sequence Context. It contains fewer properties than context and one extra container: TestSockets.
3. Circular references: The Sequence Context is the main object, and it contains so-called top-level sub-properties, aka dynamic properties (not class properties, aka built-in properties). The Sequence Context top-level sub-properties are Locals, Parameters, FileGlobals, StationGlobals, ThisContext, RunState, and Step. The VariablesView control displays it as a ThisContext. The confusing part here is the circular referencing of the Sequence Context. The ThisContext object contains the sub-property ThisContext (it is a reference to itself) and the RunState, which also has ThisContext. Not to mention that all variables are also accessible from the Sequence Context class properties. See screenshots 1 and 2.
4. VariablesView control: The VariablesView control displays the Sequence Context top-level properties as they are, so with all the duplications. It would be much clearer if RunState won't shown at the top level. 

The differences are:

1. The RunState contains the TestSockets, everything except that container can be accessed in the Sequence Context.
2. The RunState is a sub-property of the Sequence Context object.
3. The RunState is the Property Object class; the ThisContext is the Sequence Context class (child class of the Property Object).
4. In the Sequence Context, most of the properties are read-only; the RunState has no such limitation (which is not cool).
5. In the RunState, the execution state is stored as dynamic sub-properties; in the Sequence Context, it is stored as class properties (built-in properties). See screenshot 2.
6. In LabVIEW, you can get the execution state from the Sequence Context simply by using property nodes; if you pass RunState, you need to use invoke nodes and know proper lookup strings. That is also the reason why it is recommended to pass the Sequence Context to the code modules - it is just easier. However, it is possible to use both. See screenshot 3.

Additional information

The Sequence Context is a reference to the run-time copy of a sequence created when initiating an Execution. The VaraiblesView control displays it as the ThisContext, and it contains the context of the sequence you see in the GUI (when editing or pausing execution). When running, it contains the context of the sequence at the place (and time) the execution pointer points.    

Final thoughts

IMHO the RunState property is redundant (if we ignore TestSockets) and creates a lot of confusion. I don't know why it was added in the first place. Maybe it is there to make the execution state easily accessible during debugging? Or it could be explained with some TestStand history study? Perhaps there may have been no Auto-Completion in the expression field, and you could only drag and drop variables from the VariableView control? That could explain why TestStand designers decided to expose the Sequence Context class properties through additional top-level sub-property (even though it is a duplication and can't be read-only).

Screenshot 1

Screenshot 2

Screenshot 3