TestStand Types

[hansf]

We have a large TestStand project with multiple development PCs and developers.  We are using Perforce to source control and share our work. We have created some custom type files which are in the Teststand\Components\User\TypePalettes directory which we have put under source control.  This has worked well in the past.

We recently upgraded to TestStand 4.0.  Subsequently, we decided to customize the order of the Step Types in the insertion palette.  After customizing the Step Type Menu, all of the type files under NI's directory and the User directory in the Type Palette are starred indicating that they all have changes to be saved.

If we save all the type files on that PC and then check in our custom type files under \User, we would like to be able to go to our other development PCs and get the latest revision of the type palettes in the \User directory and have those other PCs show the new step type menu structure.  That does not happen unless we also copy the \NI\TypePalettes\NI_Types.ini file to the other PCs.

We have three workarounds, all of which have negative consequences:

1) Leave NI_Types.ini out of source control and manually copy it to the \NI directory of each development PC every time we change the Step Type Menu. 
The bad: prone to error if a copy is not done on one station or if the wrong version of NI_Types is copied.

2) Copy NI_Types.ini from the \NI to the \User add add it to source control.  This allows us to automatically update our Step Type Menus across all the dev PCs just by getting the latest revision of \User from Perforce.  
The bad:  TestStand now shows two versions of NI_Types in the Type Palette, one from \NI and one from \User.  We had hoped that once TestStand found NI_types.ini in \User, it would no longer use the one in \NI, as happens with other files that are copied from \NI to \User such as the sequential model.

3) Do 2) and additionally manually delete NI_types.ini from \NI on each dev PC. 
The bad:  It's a manual operation that will have to be remembered for each existing dev PC and any new ones we buy. Then when we upgrade to a future TestStand version, we're guessing that NI_Types.ini will again show up in \NI so we'll have to manually delete it on each PC again.


Questions

1) Is it a bug that a TestStand modification such as editing the Step Type Menu makes changes to files outside of \User?  It does create problems for us.  We thought the whole point of \User was to avoid these types of issues.

2) Is there a better workaround than what we have come up with?

Thanks,
Hans

[dug9000]

Hans,

The currently used configuration for the step type order is actually saved in the testexec.ini file in your config directory. If you update the version of the testexec.ini on your machines to the same as the machine in which you modified the type order then you should get the modified order on those machines as well (it's the TypeGroup settings inside the testexec.ini file).

The reason why this information is also stored in every type palette is so that when a new type palette is moved to another machine it will try and place its types in the same relative location as they were on the machine on which the palette was last saved. This is mostly for people distributing their step types to 3rd parties and wanting to control the initial location of the step types on those machines.

Hope this information helps,
-Doug

[hansf]

Hi Doug,

Thanks for the reply.  It does help to know that testexec.ini stores the step type menu order.  However, from what we saw, changing the menu order of a NI step type also requires that NI_Types.ini be updated.

After we made the Step Type Menu change of moving the location of the NI Goto step type within the menu tree, we updated the testexec.ini file on the dev PCs to match the copy on the PC where the menu order of the Goto step type was changed.  We did not see the step type menu change correctly until I also updated NI_Types.ini, apparently because NI_Types.ini still reflected the old menu order.

Also, before I updated NI_Types.ini, TestStand gave me a Goto type conflict error when executing sequence files that came with TestStand such as the Sequence File Updater.  This occurred even though no change was made to the Goto step type other than its menu location and even though testexec.ini had been updated.  After I also copied the updated NI_Types.ini, the type conflict error went away and the step type menu matched the PC where the menu change was made.

I can understand wanting to control where step types from a new palette appear on other PCs, but its doesn't seem correct that merely moving a type's location in the menu forces all the type palettes to be updated and causes type conflict errors in sequences that use the type.  It seems like a separate file could be used to contain all the step type menu location information so the type palettes aren't impacted by menu changes.

Hans

[dug9000]

You are right, there is a setting on step types "Menu Group" that can get changed when you reorder the menu. If you change the menu group of a step type you will need to distribute that step type's type palette as well. If you don't change the menu group then the step type is not edited, however the customization of the menu is limited if you avoid changing the menu groups. Your suggestion is a good one. I'll pass it along.

Thanks,
-Doug

[hansf]

Hi Doug,

OK - thanks for your help and explanations.  Now we understand the how the step type menu info is stored, so we can work with it.

Hans