Error and CommonResults

TestStand 2019 Help

Edition Date: May 2019

Part Number: 370052AA-01

»View Product Info
Download Help (Windows Only)

TestStand inserts a Results property in every step you add to a sequence. The Results property includes at least three subproperties—Error, Status, and Common.

Steps use the Error subproperty to indicate run-time errors. The Error subproperty uses the Error standard data type, which is a container that includes Code, Msg, and Occurred subproperties. When a run-time error occurs in a step, the step sets the Code subproperty to a value that indicates the source of the error, the Msg subproperty to a string that describes the error, and the Occurred subproperty to True.

The Common subproperty uses the CommonResults standard data type, which is an initially empty object. By adding subproperties to the CommonResults data type, you can add extra result information to all steps in a standard way.

The default CommonResults standard data type version ( is empty and does not change in newer versions of TestStand to ensure that any use of a newer version of CommonResults in sequence files is maintained and not automatically overridden in a newer version of TestStand.

Note Note  TestStand 4.1 or later includes code to handle an issue in which sequence files with an unsupported version of CommonResults ( were made publicly available. If you load a file with an empty CommonResults data type, TestStand does not automatically use that version of the data type and instead uses the existing global version. This behavior ensures that TestStand does not automatically propagate this unintentionally released version of the type to other files.

In addition, when TestStand attempts to load two versions of the CommonResults data type and one version of the data type is defined as an empty container and has a version of or earlier, and the other version of the data type is defined as a non-empty container, TestStand does not allow the empty version to automatically override the non-empty version, even if the empty version has a later version number. This behavior ensures that TestStand does not automatically lose changes made to CommonResults in versions of TestStand earlier than TestStand 3.1.

When you modify CommonResults without incrementing the version number, you might see a type conflict when you open other sequence files, such as FrontEndCallbacks.seq when TestStand loads the LoginLogout Front-End callback sequence before you log in or out. TestStand prompts you to increment the version number when you save changes to any data type or step type. You can avoid the type conflicts by resaving the type palette files and instructing TestStand to increment the type version for CommonResults before opening any other files. National Instruments recommends modifying the CommonResults data type only when you want to make an architectural change to all step types that you use. Share the modified CommonResults data type and the step types that use the CommonResults data type only with systems on which you are certain you will not deploy any conflicting changes to CommonResults. If you want to add additional results to particular steps, National Instruments recommends using the Additional Results feature rather than modifying CommonResults.

See Also

Type Concepts


Not Helpful