In NI TestStand 4.2, adding SequenceFilePostResultListEntry should not directly re-enable Record Results on unrelated steps. The callback is copied into the sequence file; it does not, by itself, edit other sequences. Treat callback code that changes the setting and leaves it changed, or an unintended edit such as Undo, as hypotheses requiring controlled reproduction.
Observed behavior and expected boundary
| Condition | Evidence-supported observation | Engineering interpretation |
|---|---|---|
| Record Results cleared, file saved, sequence run | The check box returns in some sequences. | The affected sequences and step types remain unidentified. |
| Callback removed | Behavior returns to what the user expects. | The callback or its code is correlated with the change, but causation is not yet isolated. |
| Callback added | The flag changes again. | Inspect callback operations and reproduce the change under controlled conditions. |
Inspect the callback before changing result strategy
Review every operation executed by SequenceFilePostResultListEntry. Determine whether the callback writes a result-collection setting directly or calls code that does so. If it changes a setting, verify that the callback restores the prior value before it completes. Adding the callback alone has no identified mechanism for modifying unrelated sequences.
The callback was intended to build a result string for transmission to a remote machine through Windows message queues. Keep that transport objective separate from the unexplained editor-state change: first establish whether callback code changes Record Results, then decide whether selected-step result collection supplies the required message data.
Run a controlled reproduction
- Create an exact inventory of the sequences and step types whose Record Results check box changes.
- Clear Record Results, save the sequence file, and record the state before execution.
- Run the sequence without
SequenceFilePostResultListEntryand record whether each monitored step changes. - Add the callback without adding setting-modification code, repeat the same run, and compare the same steps.
- Add the callback logic incrementally until the change returns. Inspect the first added operation associated with the change.
- Exclude unintended editor actions, including
Ctrl+Z, from the reproduction.
Interpret the result
If the flag changes only after particular callback logic is added, investigate that logic and any operations it invokes. If merely inserting an otherwise unmodified callback reproduces the issue, preserve the exact sequence file, affected sequence names, step types, and reproduction procedure for escalation through an official NI support channel. The available evidence identifies no known TestStand 4.2 issue that automatically changes this setting.
FAQ
Does SequenceFilePostResultListEntry enable Record Results in TestStand 4.2?
No such automatic behavior is established. Adding the callback copies its sequence into the sequence file and should not edit unrelated sequences.
Why does Record Results return after I run a TestStand sequence?
Inspect the callback and anything it calls for code that changes the setting without restoring it. Also reproduce the issue while excluding unintended Ctrl+Z input.
How do I prove whether a TestStand callback changes Record Results?
Record the affected sequences and step types, run once without the callback, then add the callback and its logic incrementally. Compare the same saved settings after each run to identify the first change that triggers the behavior.
