NI TestStand Idea Exchange

A customer noticed odd behavior when modifying custom data types in TestStand.  After reproducing the behavior, I think it's a better product suggestion because it looks as if what the customer notices is more of a design choice implemented by our software developers than a feature that is not behaving correctly.

The customer, David, created a custom type called DavidsType which was composed of a container and within this container was a collection of strings:

He then created an instance of this type in his DavidTest.seq file under the file global variables.  He called the instance MyType.

Then he goes back to the Types pane and modifies the structure of the custom data type to include another string with a default value of "C".

However, when he goes back to view the already created instance of his data type (MyType) within the variables pane of DavidTest.seq, he notices that only the structure is updated and not the default value.

New instances of the custom data type, however, do show up with the default value as shown below by MyType_Instance2.

The problem is that the customer has many instances of this type that already exist within his code.  He would currently have to create new instances of each type to load the new default value or he would have to hunt down all of the current instances and enter the default value of the new string manually.  I understand that the structure is updated, but shouldn't we build/provide an option to scan current instances of the custom data type and update default values for the elements that are new to a custom data type's structure?

I understand that it is expected behavior to load the default values of a custom data type only with a new instance of said custom data type, but I think we should provide an option/tool/function to our customers which updates all preexisting instances with the default value as well as the change in structure to the current types.  Currently only the structure is updated with a null string.

Let's say we have a parameter to a subsequence of a named type, and we want to create a so-named Local or FileGlobal with the same type.

One way to do this with our current workflow is to:

• Type the same property name in the parameter value
• Right-click the parameter
• Click on "Create Locals.whatever"
• mouse over the types menu
• Glance through most of the types, select the custom type

I'm proposing a simpler workflow for cases when you just want to duplicate or "clone" the property with the same name and type in Locals or FileGlobals:

• Right-click the empty parameter value
• Select "Create Locals.whatever" or "Create FileGlobals.whatever"

The respective menu options would appear if the so-named variable does not already exist.

The subproperty is created in the Locals or FileGlobals with the same type as the parameter.

I was pretty surprised that this isn't already possible or that there wasn't an idea in the ideas exchange for it. The idea is to allow custom step types to embed their 'edit' dialogue into the configuration tab for the step settings. At the moment you have to click a generic 'edit <step type>' button to launch a dialogue.

Instead of:

Have:

This would make custom step types much more user friendly and save unnecessary clicks/steps required to custom and bring the experience of configuring steps more in line with the built-in step types.

I appreciate that it might require a little more effort on the developers part (e.g. posting new values on value change instead of on 'ok'/'cancel') but it could also help to avoid some issues like 'hanging' TestStand when the dialogue is closed and the panel close isn't disabled/handled.