NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Type List Order Numbers (typelistordernum) change when opening a sequence file in Test Stand

Let's setup some common terminology in order to avoid confusion:

 

Type Conflicts --- Generally I don't call something a type conflict unless the user gets a type conflict resolution or error dialog. Automatically resolved conflicts I don't generally call conflicts because from the user's point of view the file loaded and works fine.

 

Type Conflicts, as I've defined them where a dialog is displayed to the user and requires some sort of intervention for things to work, should never happen if you follow this set of best practices:

 

1) All types should be in type palette files and all types should use the default settings for type conflict resolution and thus have their versions updated automatically whenever they are saved.

2) Modifications of a type should only ever be done to the version in the type palette, and that version should then be shared with everyone via source control or some other mechanism.

3) Modification of types should be under some sort of centralized control to avoid multiple developers both trying to modify the same type at the same time. Depending on your source control provider, there might be settings you can use on your type palette files which will mark them as requiring exclusive access when checked out.

4) All developers should get down the latest version of the type palette files whenever getting down new versions of sequence files.

 

You say, "So, once a file with conflicts slips through it has to be saved. Otherwise, the IDE will not run. "

 

But this is not generally true. Why does the IDE not run just because a file is marked as modified? The UI's we ship with teststand do not behave this way. They will run files marked as modified. The editor will too, though it does prompt to save the files first to avoid losing edits.

 

You give a list of what you want to happen instead which sounds very much like what teststand already does if you disable automatic conflict resolution. I don't recommend this though as it requires you to update all files whenever a type changes to avoid these prompts to the user. I'm still not clear on why you want that unless you want to make sure all of your files are always up to date with the latest version of the types, but I don't think that's really worth the trouble since the automatic conflict resolution exists precisely in the cases in which there is no point asking the user how to resolve the conflict because the type developer has already told us how.

 

You say, "I prefer to see the IDE as less rather than more proactive. I would much prefer if the IDE will tag the file as having a conflict, point to the conflict and allow me to resolve it as I described about".

 

TestStand already prompts to resolve conflicts when opening a file if you disable automatic conflict resolution (either globally or on a per type basis). Is there something that is insufficient about how we currently do this that causes problems for you? It seems to me that what you are proposing would have exactly the same issues as the existing mechanism already does. Though perhaps I am misunderstanding what you are asking for.

 

You say, "I tried to use the tool but decided to pass because I was unclear as to what type will be used to replace the conflicting types. The tool mentions the loaded type. But which is the loaded part is unclear."

 

The Type Palette files are loaded by the tool, and if you follow best practices, all of your types should be in type palette files and the type palette files should always have the highest version of the type, so that is the one you should get.

 

From what you've written, I think you might have some misconceptions about how automatic type conflict resolution works and what its purpose is. Basically, the purpose of automatic type conflict resolution is so that the type developer can specify that they always want sequences to automatically upgrade to the latest version of the type, which is typically stored in a type palette file, because they have designed their type in such a way that this is always the correct thing to do. Thus there is no need to ever prompt the user what to do when they load a sequence file with an older version of the type. If you don't like this feature you can either disable it on a per type basis (on the version tab for the type), or on a global bases (in the station options dialog on the file tab). If you disable automatic conflict resolution, you will then always be prompted whenever a sequence file is loaded with a type that does not match the version of that type that is currently loaded. All files opened by teststand must use the same version of a type, thus some sort of decision needs to be made when such a conflict occurs. It makes sense if you think about it because imagine a sequence file calling a sequence in another file and passing an instance of a data type, if they didn't agree on what the structure of that data type was, it could lead to unexpected runtime errors. In general, I think it's best to centralize your type management and automatically update all developers to use the latest version of your types using type palettes and automatic conflict resolution. That way the type developer can ensure backwards compatibility and the end user of the type never needs to work about how to resolve type conflicts.

 

Hope this helps make things a bit clearer.

-Doug

0 Kudos
Message 21 of 22
(538 Views)

Thanks for the long answer.

 

At this point it seems to me that we are not seeing things eye to eye and have reached an impasse.

 

0 Kudos
Message 22 of 22
(534 Views)