NI TestStand Idea Exchange

As NI has acknowledged (here, here) for more than 5 years, the Build .sql File button creates schemas with errors.  This is even true for the default schemas in the left of the dialog.  Would be great if NI would go ahead and correct this.  BTW - to create default tables in the meantime, a developer should use a SQL file located here:  <TestStand>\Components\Models\TestStandModels\Database

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.

We found a need to customize the NI version of this step to give more functionality.  Our edits updates to allow multiple response text boxes (up to 10), and we added an option to configure the response to be a list controls rather than simple strings. Just added a Boolean to switch to list box and then the user just gives comma separated list of options with the default item first as the initial response string.

This is a simple change to the step and allows far greater flexibility for the step type (also it was easy to make the step upgradeable from the exiting step version maintainign the functionality if one or no string responses being used).

These features are very useful for collecting all UUT information during PreUUT rather than having to throw up popup after popup or create a custom module with a popup in it.  Would be great if these features could be included in the standard NI step.