TS Types. Order of loading

[MimiKLM]

From http://www.ni.com/white-paper/7060/en/ I know that order of the loading types is like below:

=========================================================================================

===============================================================================================

My question is regarding the Type palette files. Which ones are processed first? The files from C:\Program Files\National Instruments\TestStand 2010 SP1\Components\TypePalettes\ or from C:\Users\Public\Documents\National Instruments\TestStand 2010 SP1\Components\TypePalettes\ location?

Also in C:\Program Files\National Instruments\TestStand 2010 SP1\Components\Compatibility there are folders contain version dependend type definitions. How are they trated during TS loading?

And finally, what is the the order of loading the files which are in one directory? Is the order of loading alfabetical?

[CharlotteN]

Hi MimiKLM, 

Are these questions in regards to conflicts that might arise in TestStand? Is there a particular reason for these questions? 

The default setting for which directory is accessed first when looking for type palettes is the Program Files folder before the Users folder. However you can change the order by going to Configure > Edit Search Directories. 

TestStand will automatically pick the type with the newest version. However there is a caveats to this - if any type has the modified checkbox ticked in Type Properties > Version this will no longer be the case.

I cannot find an explicit answer to whether, in a directory, the items are accessed in alphabetical order. Everything implies that this is the case though. 

Hope that helps you out, 

Charlotte N. 

[dug9000]

The type palettes in the program files directory are loaded first, however the order in which type palette files are loaded should not matter with default settings for recent versions of TestStand because recent versions of TestStand will give you a type conflict error if any of your type palettes have a different version of a type and you will have to resolve the conflict manually. In general you should try to keep all types that are shared between type palette files in sync to avoid type conflict errors. The type conflict errors are there to protect you from unintended type propagation, so I would not recommend disabling that feature.

The files in the Compatibility subdirectory are used purely for implementing the "Save As Previous" feature for when you save a file for use with an earlier version of TestStand by using the "Save As" dialog and selecting an older version of TestStand from the "filter" drown down list control.

I do not think there is a well defined order when selecting multiple files with an open file dialog. I think it's best not to rely on the order in this case. If possible, I'd recommend designing your system so that the order doesn't matter. For type conflict issues, the best way to avoid conflicts due to file loading order is to keep all of your types in a type palette file.

Hope this helps,

-Doug

[MimiKLM]

---

@dug9000 wrote:

The type palettes in the program files directory are loaded first, however the order in which type palette files are loaded should not matter with default settings for recent versions of TestStand because recent versions of TestStand will give you a type conflict error if any of your type palettes have a different version of a type and you will have to resolve the conflict manually.(...)

---

I think it does matter, because although I do know what is conflicting with what, I don't know what was loaded firstly. Please have a look into first post in this thread. TS says there is something in memory but it doesn't show from where it was loaded (marked as red). So, that is why I need to know the order and what is loaded first.

I'm happy to enable auto conflict resolution on, but only if I know what is going in "manual" mode

[dug9000]

Did you change the default station option setting to never automatically resolve conflicts? What version of TestStand are you using?

Some types, such as CommonResults are special built-in engine types, which are initially created dynamically by the engine (not loaded from a file). CommonResults is even more of a special case in that TestStand typically allows resolving to a newer version automatically if the older version is one of the empty default versions that has ever shipped with a version of TestStand and the newer version is non-empty. At least that is the case with the default station option setting of Allow Automatic Type Conflict Resolution: Only if Type Palette Files will not be Modified and the older version of the type is the dynamically created engine type. If you aren't using the default "Allow Automatic Type Conflict Resolution" setting please explain why and what you are trying to accomplish. If you are using the "Never" option that is likely the root cause of the conflicts you are seeing. All of the type palette files likely have a different version than the dynamically created version of CommonResults, thus you will contually get conflicts if you don't choose to resolve to the newer version of the type on in the conflict resolution dialog.

Hope this helps clarify things,

-Doug

[MimiKLM]

---

@dug9000 wrote:

Did you change the default station option setting to never automatically resolve conflicts? What version of TestStand are you using?

---

Yes I did cange default station option setting to never automatically resolve conflicts to track what'sgoing on.

The version I'm using is TS2010SP1.

---

@dug9000 wrote:

Some types, such as CommonResults are special built-in engine types, which are initially created dynamically by the engine (not loaded from a file).

---

Could you please extend the topic about the special built-in engine types? Or/and point me to some documentation on  this topic?

Cheers.

[dug9000]

If you want to be more strict, I'd recommend using the setting "Only if a Type Palette File has the Higher Version" rather than "Never". "Only if a Type Palette File has the Higher Version" is more strict than the default in that conflicts between two sequence files where the type does not exist in a type palette file at all, will never get resolved automatically. It does seem like somewhat of an oversight that with the "Never" setting you will always get a conflict if you have modified the CommonResults type. I will record this as an issue to perhaps address in a future version of TestStand.

Most engine types are not user editable, and you should not get conflicts due to the non-editable engine types (even when using the "Never" option. This is because they are handled as a special case when it comes to automatic conflict resolution.). The non-editable engine types are things like FlexCStepAdditions (and other adapter specific types), TEInf, NI_CustomResult, Expression, Path, Error, etc. Most of these appear in the type palettes view under the Standard Data Types category. Basically they are types that are fundamental to the functioning of the engine and adapters. The two exceptions to this are the engine types CommonResults and NI_UserCustomPrivileges which are user editable. These two are really the only engine types that should give you any problems with the "Never" option. It is most likely an oversight that they aren't handled specially with the "Never" option.

I'm not sure if there is specific documentation on these separate from the documentation about standard data types, perhaps not, but in most cases it's not important to distinguish them from other standard data types, the behavior is essentially identical for most purposes. CommonResults and NI_UserCustomPrivileges are the rare exceptions.

Let me know if you have any questions or require any additional information.

Hope this helps,

-Doug

[dug9000]

NOTE: I've logged the issue in our tracking database with ID: 509895.