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.
