Hi, I found some strange behavior in TestStand. It is as described in known issues https://www.ni.com/pl-pl/support/documentation/bugs/19/teststand-2019-known-issues.html#662205_by_Category but not for the array of clusters but just for clusters.
So, I have a problem to update the container type definition containing enum type definition in TestStand.
The example is as follows:
- Create a sequence file with a LabVIEW call.
- Called VI will have a cluster containing numeric, string and typedef enum.
- Create a type definition for this cluster in TestStand by clicking on Create/Update Custom Datat Type... button in the type column for the code module parameter.
- Create a new parameter with the newly created type.
Now all is working as it is in attached EnumUpdateBug_1.seq. We have 2 new type definitions in TestStand: one for cluster and one for enum.
Next, try to update the enum definition in LabVIEW and later in TestStand.
- Change LabVIEW enum type definition - e.g. change one item text (see EnumUpdateBug_2.seq).
- Then, in TestStand you will see the red exclamation mark because you changed the VI. Click on it and let TestStand accept the fact.
- We don't see any issues at first glance, but then if we check enum in our parameters we can see that we don't have the same enum that we have in LabVIEW. If we click to check expression (red checkmark) where our parameter is used in the code module we see "no errors". But when we click Create/Update Custom Datat Type... button again. Then we see that we have a mismatch. It suggests using a new data type for our enum - it doesn't want to automatically link it with our enum typedef...
We need to uncheck "Force Exact Match" and manually select types...
After we click Update we don't see any changes. Our updated type definition remains the same - enum looks like it was before, no update. Our LabVIEW call seems to be ok (no red marks of any sort) but if we look closer we can see the message...
To me, it looks like the bug described in know issues but just with clusters. The suggested workaround is not really helpful if you need to manually update the type everywhere...
