Hi huizhong,
The type conflict dialog you are seeing is evidence that the copy of
CommonResults (an NI-Installed type) in the sequence file has the same version but different settings than the currently loaded
CommonResults type definition.
CommonResults
is stored in almost all of the built in TestStand type palettes which
automatically get loaded when you open TestStand. Because of this, it
becomes a part of the global type usage list in the Engine. If you
didn't make any changes to
CommonResults yourself, it is likely you have inherited a type virus from somewhere and I suggest you take measures to correct the problem.
A
type virus can spread when you tell TestStand to resolve a type
conflict by using the version from the file you are currently opening
(as opposed to the currently loaded type in the global type usage
list). Once the "new" type is copied over to the type palettes, it will
then get loaded every time TestStand runs. At this point, if you open
up more files that use this same type and choose to use the currently
loaded type when the type conflict dialog shows, TestStand will copy
the "new" version into the file - thus the spread or viral like
behavior.
In order to correct the problem, you can either:
- Manually open each and every infected file and replace the invalid type with the valid type or...
- Use the Type Differ tool that I wrote to inspect each file pair and merge the conflict automatically
I
realize that using the Type Differ at this point is still "manual" in
the sense that you must open each file pair and merge the conflict, but
hopefully in your case there aren't that many affected files. To that
end, I am working on a Batch version of the Type Differ that can diff
and merge entire directory structures automatically. Let me know if you
are interested in using such a tool and I will post a link when
development has reached a beta version.
Regards,