Type definition and reference

Question

Hello,
when I look at the "Usage" column in the Types view, am I right to assume that the first location given for a type is where the type is defined, all others where it is referenced?
Example:
Name                 Type                           Version    Usage
OMS_StdQueueInput    Container, Type Definition     0.0.0.4    OMS_Types.ini; OMS_LocalTypes.ini; OMSStart.seq    No comment
So here I would assume, that the type OMS_StdQueueInput is defined in OMS_Types.ini and used/referenced in OMS_LocalTypes.ini and OMSStart.seq. Is that correct?
Regards,
Peter
Solved!
Go to Solution.

Answer 1

By INI file do you mean a TestStand Type Palette File?
A new feature was added to TestStand (in 4.1 I think so you should have it) that allows you to control when automatic conflict resolution (choosing the highest version of  a type silently) occurs. The setting is located on the File tab of the Station Options dialog and is called "Allow Automatic Type Conflict Resolution". In general, I recommend changing it to the slightly more restrictive setting of "Only If a Type Palette File has the Higher Version" because this will get rid of the possibility of automatic conflict resolution when opening two sequence files with different versions of a type when the type does not exist in a type palette file. But if your type will always be in a type palette file then the default setting is fine.
First, some background information.
Automatic Type Conflict Resolution - This occurs when a file is opened whose type is different from the version already loaded into memory, and the criteria for automatic resolution is met (i.e. the station option setting allows it, neither verison of the type is marked as modified, and the different versions of the type have different version numbers). When automatic resolution occurs TestStand automatically chooses the version of the type with the highest version number.
Let me know if you want me to explain other terms.
What I'd recommend for type management:
1) Create a type palette file for your standard types. Make sure all deployed and development systems are using/loading this type palette file. If you need more details on how to do this please let us know.
2) Control updates to these types using a source code control system to control updating of the type palette file(s). Ideally, only one person should be editing a type palette file at a time. Source code control systems can be used to enforce this.
3) Let your developers know that they should only edit types in the type palette files and not in individual sequence files.
4) Try to make all changes to your types and substep code backwards compatible so that old sequences will continue to work with newer versions of the types. If you have to break backwards compatibility, consider creating a new type instead and use the new type from now on, but leave the old type there for backwards compatibility (you can use flags to hide the old version of the types from the insert menu if needed).
If you use a type palette file in this way I think you will get something close to what you are asking for. With the default setting for "Allow Automatic Type Conflict Resolution", if all of your TestStand systems are loading your standard type palette files then you will either get the version in the type palette file or your will get a type conflict dialog if the version in the sequence file is newer. There will be no possibility of silently using a version other than the one in the type palette file. Is this sufficient for your needs or are you looking for something different. If you are looking for something different please let us know the specific behavior you require.
Hope this helps,
-Doug