Hi All,
I have come across the following unfortunate situation in teststand, for which I would like some explanation.
I thought it was best to illustrate my findings with screenshots and explain the problem that way.
For my application, I wish to read a 'testcase' struct coming from a C# module that returns it. This 'testcase' struct contains some named string fields (id, idVAS, title,...) and a 'configMeasurement'-field that contains multiple 'parameter' structs. I first defined the 'parameter' type, for which I used the 'create Type from struct' button, afterwards I defined the 'testcase' datatype, by also using that button.
Then I created a local variable, called 'struct', using the newly defined 'testcase' struct datatype. But when I tried to place this new variable in the value field of the return value, it complained that the configMeasurement was not of the type 'array of containers'. So I headed to the type definitions and edited the type so configMeasurement is now an 'array of parameters'. This is shown in next picture:
However, when I then again filled in the 'struct'-variable in the return value, it still complained that the expected type and the declared type are not the same.
So then I tried to link each element of the returned struct, to the corresponding element in the teststand struct. Which worked without any errors.
The result:
So my question is.. why this is happening, why do I need to split and link both the structs?
Our structs will vary for each testcase, mainly in number of parameters, but in the future we could (and we will) add some more elements or other arrays of structs. I prefer not to change the testStand code every time a parameter is added, or changed, since that will be happening in a database we will be reading from C#.
What I want is my teststand code to be generic, so that it can handle any type of struct I pass from that return value:
- My module passes the struct to teststand,
- Use the testStand API to define the type according to the struct
- Use the struct variables
Any help on this matter is very much appreciated.