By default, LabVIEW stores compiled code together with the VI file. This is something transparent to us and we don't pay much attention to it. However, this can cause problems which appear when editing your VI. Sometimes when we edit a single VI, we notice that a number of other VIs require saving. Even though we haven't changed them directly. This is especially painful when trying to keep things in order with source code control.
In this video tutorial, I go through the new feature in LabVIEW 2010 which allows you to separate compiled code from your VIs. This allows you to avoid the problem of propagating changes.
Download: Code used in this tutorial (LabVIEW 2010)
Have you started using this new feature? Let me know in the comments.
*Update*
I have some additional information that I learned after making this video. Thanks to Danny for commenting which prompted me to do some more research:
- Any diagram that contains a ExpressVI or a Statechart VI cannot separate source and object code due to how LabVIEW embeds those subVIs inside their caller. Also a PolyVI can't be marked, because it doesn't really have a diagram (although an instance of a PolyVI can be).
- The term now used to describe a VI that does not have its compiled code separated, is: “uni-file”
- At the end of the video, I describe a caveat. To clarify this a bit more. What this basically means is that in order to do dynamic loading of VIs from the LabVIEW Run-Time engine, (as is the case in built executables which call VIs) you must not separate compiled code from VIs. In other words, you must create uni-files.
- In the video, I show how to turn this on for a VI or even the contents of a Project file, but there is a way to enable this feature by default so that any and all new VIs are saved as “source-only” VIs. This can be done using an ini token: SourceOnlyEnvironment=True. As with any “secret” ini token, it's not supported and it's considered experimental. One side affect to be wary of is that you cannot create a normal “uni-file” with this setting enabled (the VI Property setting is ignored), which is required for dynamically loaded VIs.
