Inside the Build Specification properties, there's an option "Additional Exclusions" -> "Disconnect type definitions".
The only piece of documentation I've found is at http://zone.ni.com/reference/en-XX/help/371361H-01/lvdialog/additional_exclusions_sd/ but it's not very descriptive. It suggests that disconnecting might cause front panel objects to be displayed incorrectly. Is this the case?
What does this option do? Its existence suggests to me that type definition info persists inside a compiled LabVIEW application, unless we choose to disconnect them.
When should I disconnect, and when should I leave type definitions alone?
Thanks in advance!
I only know one use case for this option: when application builder throws errors during builds or exe itself doesnt work.
One reason to use it is when you use Network Shared Variables with typedefs - I recall problems with shared variables not founding theirs typedefs after build. This option also happens to fix more exotic problems - see LV2014 bug fixes:
|426523||A specific large project fails to build with a GenIL error and then crashes if you do not select Disconnect Type Defs|
So, other than to workaround app builder problems - I don't know any other reason to mark Disconnect Type Definitions.
Thanks for sharing your observations, PiDi.
I've also noticed a few cases where some CompactRIO code runs fine from source code, but won't start for some mysterious reason when built and deployed. The workaround was to disconnect the type definitions.
It would be great if someone from NI could provide more insight into the topic.
Type definitions are used to preserve source code - however, when building/running an executable, this is not a priority. In this case, type definitions can be disconnected to preserve memory usage. The disconnect option is also used as a troubleshooting step when LabVIEW perceives conflicts among different type definitions. The Additional Exclusions Page for LabVIEW 2014 offers a little more information than the 2011 version:
Thanks, Kristen! Your explanation and link answered 2 out of 3 questions from my last post:
This leads to other questions:
There was a bug in LV2011 RT that caused RT executables to not run when deployed if you had type-def bound shared variables in your project/application. I know because this caused no end of headaches trying to debug why on earth my executable wasn't running when deployed (but would in any other circumstances). Disconnecting the typedefs of the shared variables fixed it for me.
I know this thread is quite old but i stumbled upon it and I have one more case in which that option might be useful:
If you have a enumeration typedefinition and encounter changes to a constant of that enumeration type in a built executable, the problem might be solved by setting this option.
( I know "constant" and "changes" should exclude each other but it happened to me.