type definition and reference

[pwaszkewitz]

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

[Norbert_B]

Peter,

i have not found any documentation about this but your observation concurs with mine. The only documentation i found states:

The Usage column shows the files that use each type.

Regarding your example, i would also think that OMS_StdQueueInput is originally defined in OMS_Types.ini, used in OMS_LocalTypes.ini (e.g. used in a container or in a step type) and it is definetly used in OMSStart.seq. But it is not clear if the OMS_StdQueueInput is used explicitly in the OMSStart.seq or implicitly by using the type defined in OMS_LocalTypes.ini.

hope this helps,

Norbert 

[pwaszkewitz]

Norbert,

yes that helps, thank you for the confirmation.

Regards

Peter

[dug9000]

Every file which contains an instance of a type also contains a definition for it (There are some exceptions to this, but this is generally the case). This is necessary because the instances can only be recreated if you know the definition so the definition must also be stored with the file. Also TestStand needs to be able to detect and resolve any changes to the type since the file was last saved. When a file is opened, if a definition for a type it contains is already in memory, TestStand compares that definition to the one in the file and if they are different you will get a type conflict dialog to resolve the problem. Only one definition for a type can be in use/memory at a time, but every file which uses it must save a copy of the type definition with the file.

So the answer is really that it is defined in all of those files and that the order doesn't matter.

Are you seeing a problem related to this that you need help with?

Hope this helps. Let me know if this explanation is unclear or if you need more details.

-Doug

[pwaszkewitz]

Thanks for the clarification!

I completely understand the necessity of keeping a copy of the types in the files using the type.

I am trying to figure out if I actually have a problem with that or if it is just the gut reaction of a programmer who had one too many problems with the "One Definition Rule". Let me describe our scenario.

We have certain basic custom data types which we want to be the same at least on all machines in a single project, possibly over several projects, until we see a reason to update that type. Now we have these types in INI files which are copied to the individual projects / machines from a template (not in the Sequence Editor sense, just a basic project directory). With the default setting for type conflicts in TestStand 4.1, sequence files will be automatically updated when someone changes the definition in the INI file, which is fine because a sequence file is local to the machine. On the other hand, if someone changes the type in a sequence file, he gets a type conflict reported and can only use his change when he has the INI file updated.

Now he has a version of an INI file from the project standard with a newer type than the standard INI file. This conflict may recur, when the standard file is deployed again. Worse, there may be conflicting changes to the standard and the type in the sequence file. To avoid this, I would like it if the definition in the standard INI file could be declared as the only "canonical" definition so that changes to the type always haveto be done there.

Perhaps I am thinking too much in the way of a C programmer who is used to having type definitions in his header files and only there and one has to approach it differently in TestStand. But I think it could also be helpful, especially for larger projects and organizations who want a degree of standardization, to be able to enforce certain definitions.

Regards

Peter

[dug9000 · Accepted solution]

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

[pwaszkewitz]

Yes, by INI file I mean a type palette file.

I had about the same procedure in mind as you outlined. Glad to have the confirmation that this is a sensible method.

Thank you for the suggestion to use the more restrictive setting for the automatic conflict resolution, that is exactly what I was looking for! Also thanks for the hint about backwards compatibility, it is easy to miss that.

Best regards

Peter