|LabVIEW 2016 Help|
|LabVIEW 2017 Help|
|LabVIEW 2018 Help|
|LabVIEW 2019 Help|
|LabVIEW 2020 Help|
By default, a VI contains two kinds of code: the graphical source code that you edit and a compiled version of this code that LabVIEW uses to run the VI. When you edit the source code of the VI, LabVIEW automatically recompiles the VI to reflect your changes in the compiled version of the code. LabVIEW also automatically recompiles all VIs that call the changed VI, resulting in unsaved changes to the calling VIs. If the calling VIs are stored in source control, these pending unsaved changes force you to check out the VIs when you update their subVIs.
To avoid this problem, LabVIEW allows you to separate compiled code from the graphical source code of a VI, thereby creating source-only VIs. After you separate the compiled code from a VI, LabVIEW still compiles the VI when you modify subVIs. However, LabVIEW stores the recompiled version of the code in a compiled object cache rather than in the VI in source control. Because the VI in source control does not change, you no longer have to check the VI out of source control when you change subVIs.
Separate compiled code from VIs for the following reasons:
LabVIEW also allows you to create source-only project libraries, LabVIEW classes, and XControls that prevent member files from causing unsaved changes in the versions stored in source control. Unlike for source-only VIs, LabVIEW does not actually separate compiled code from these file types, some of which do not even contain compiled code. Instead, when you select the Separate compiled code from source file option for these file types, LabVIEW stores an up-to-date version of each file in the object cache. If you change a member VI of the library, class, or XControl, LabVIEW updates the version of the file in the object cache rather than asking you to save the version that is in source control. Therefore, source-only libraries, classes, and XControls allow all the same benefits as source-only VIs.