Why do I get an "Array element prototype" -17001 error when trying to "View Paths"?

[jpolstra]

I added some custom types to my sequence file and to MyTypes.ini, and then opened and updated all of the .seq files under "Components/User". I'm a TestStand Newbie, but I think I did this correctly.

Now, if I try to "View Paths" in the sequence file, I get the following error:

Array element prototype does not have a location string!
Error Code: -17001, Program Error.
Source 'TSAPI'

Any idea what's going on?

Jim Polstra

[Jason F.]

Hi Jim,

That is a rather unusual problem you have encountered.

Could you tell me what version of TestStand you are using by going to the Sequence Editor's "Help >> About TestStand Sequence Editor" menu selection (make note of both the application and engine versoins). Could you also try giving a complete list of steps to reproduce this, along with submitting your files that have the custom types so that I can try this out in house (you can try reinstalling TestStand as a more immediate solution, but this will also give you an opportunity to reproduce the behavior yourself so that you can note what processes you went through in order to arrive at this state)?

If I can reproduce the problem, then I will have something to show to the developers so that the
y can determine what the cause of the problem is. Thanks!

Jason F.
Applications Engineer
National Instruments
www.ni.com/ask

[jpolstra]

Jason,

I'm using TestStand Engine Ver. 2.0.1f1 and Sequence Editor Ver. 2.0.1.

I have found a simpler method of producing the problem:

Open the Type Pallet, select MyTypes.ini.

Defined a Custom Type in MyTypes.ini:
{
DataFile (Container)
Direction (String)
Description (String)
FilePath (Path)
}

Save All, View Paths, check the MyTypes.ini box, verify that it works.

Define another Custom Type in MyTypes.ini:
{
DataFiles:
Array of Type DataFile (1 dim, [0..9])
}

Save All, View Paths, check the MyTypes.ini box, get the -17001 error.

This will work again if you replace the "Array of DataFile" element with an array of Strings.

It will also work if you simply remove the "FilePath" element from the definition of "Typ
e DataFile".

So it looks like the problem is with an array of a type that contains an element of "Type Path".

Jim

[Jason F.]

Jim,

Thanks for the explanation and instructions for reproducing the problem.

I was able to reproduce this here as well and this is definitely not the intended behavior. As far as when this specific problem will be fixed, you can be assured that is being addressed in future releases of TestStand. For now though, we will have to consider a workaround, and it goes as follows:

It appears that this is happening only with specific type definitions such as "Path" (we haven't identified any others but we can't rule out yet that others don't exist), and it doesn't really have to be placed inside of a custom container type such as you illustrated. If you simply create a custom type that is just an array of "Path"s it will behave the same way when you View >> Paths. What's really funny about this though is that "Path" is simply a custom type based on the "String" intrinsic type. If you create your own custom string type called "MyPath" and replace the "FilePath" field in the "DataFile" container type with a new "FilePath" field based on the "MyPath" datatype, the error won't occur. This is also exactly what we recommend as a workaround. So, simply do the following to implement this:

1) Open MyTypes.ini and create a new custom type of type "String" named "MyPath".
2) Delete the field named "FilePath" from the "DataFile" custom type.
3) Create a new field in the "DataFile" custom container type, again called "FilePath", but make it of type "MyPath".
4) Save MyTypes.ini
5) Now try doing a View >> Paths on the MyTypes.ini file as before.

As a final note, we don't really believe that much concern should be placed on this by end-users in relation to a run-time scenario, as the only thing that is really being affected by this is an edit-time tool. We acknowledge the importance of having all of the design time tools work flawlessly, but it should be made clear that this will most likely not affect anything at run-time.

I hope this helps, and thank you again for reporting this issue to us. Let me know if you need anything else.

Jason F.
Applications Engineer
National Instruments
www.ni.com/ask

[jpolstra]

Jason,

Thanks very much for your response and workaround.

The reason that I started off using the "Path" type was to make use of it's special features with respect to the TestStand Search Paths and automatic relative paths.

I think that this is a very valuable feature of TestStand because of the ease with which file locations can be changed for either debug purposes or different machine configurations by simply adjusting the Search Paths, and the Path Type makes it easy to see the file location that TestStand will use at Runtime. For that reason, it's worth fixing, but in the mean time, thanks again!

Jim