Using Libraries in LabVIEW Projects

LabVIEW project libraries are collections of VIs, type definitions, shared variables, palette files, and other files, including other project libraries. When you create and save a new project library, LabVIEW creates a project library file (.lvlib), which includes the properties of the project library and the references to files that the project library owns.

Note�� Packed project libraries are project libraries that you build with the Application Builder into a single file. You cannot modify the files in a packed library unless you make changes to the files and rebuild the packed library.

Project libraries are useful if you want to organize files into a single hierarchy of items, avoid potential VI name duplication, limit public access to certain files, limit editing permission for a collection of files, and set a default palette file for a group of VIs. You can drag items that a project library owns from the Project Explorer window to the block diagram or front panel.

You can view the structure of a project library from the Project Explorer window or in a stand-alone project library window. If you are not in the Project Explorer window, right-click a project library file and select Open from the shortcut menu to open it in the project library window.

Note��If the project library file you select is not the top-level project library file, the stand-alone window that opens is the project library window of the top-level project library. The project library file you select is in the contents tree of the top-level project library window.

Use project libraries to organize a virtual, logical hierarchy of items. A project library file does not contain the actual files it owns, unlike an LLB, which is a physical directory that contains VIs. Files that a project library owns still appear individually on disk in the directories where you saved them.

Use project libraries to qualify the names of VIs and other LabVIEW files. LabVIEW identifies VIs by filename, so LabVIEW unintentionally might load and reference a VI because the VI has the same filename as another VI, a problem known as cross-linking. When a VI is part of a project library, LabVIEW qualifies the VI name with the project library name to avoid cross-linking. A qualified name includes the filename and the qualified name of the owning project library.

For example, if you build a VI named caller.vi that includes a subVI named init.vi that library1.lvlib owns, you also can include a different subVI named init.vi that library2.lvlib owns and avoid cross-linking problems. The qualified names that LabVIEW records when you save caller.vi are library1.lvlib:init.vi and library2.lvlib:init.vi respectively.

Note�� Only one project library can own a specific VI. However, you can associate a file not specific to LabVIEW, such as a text file or HTML file, with multiple project libraries. Avoid adding a file to a new library if that file already belongs to a library. If you need to add a file that is already associated with a library to a new library, you must also add the original library for that file to the new library. Otherwise, the build output will place the file in the correct destination folder without actually adding the file to the new library.

You can specify version numbers in a project library to distinguish changes to the collection of files over time. Set version numbers from the General Settings page of the Project Library Properties dialog box and update the numbers periodically. The version number does not affect the project library name.

Caution��You must right-click the project library and select Save As or Rename from the shortcut menu to display the Save As dialog box and rename project libraries. If you rename a project library outside LabVIEW, you might break the project library.

Use project libraries to limit access to certain types of files. You can configure access to items and folders in a project library as public or private to prevent users from accessing certain items. When you set access for a folder as private, all VIs in that folder also have private access.

You can limit editing permission by locking or password-protecting project libraries. When you lock a project library, users cannot add or remove items and cannot view items that you set as private. When you assign a password to a project library, users cannot add or remove items or edit project library properties without a password. Users can open the Project Library Properties dialog box, but all dialog box components except protection options are disabled. Users must unlock the project library or enter a password to enable the dialog box components. To unlock the project library, right-click the project library and select Enter Password from the shortcut menu.

Note��When you enter a password for a library in a LabVIEW project that does not have a valid license specific to the version of LabVIEW you purchased, you cannot drag and drop items into or out of the library.

Note�� Adding password protection to a project library does not add password protection to the VIs it owns. You must assign password protection to individual VIs if you want to limit edits to the block diagrams and front panels. Consider using the same password for the project library and for the VIs the project library owns to avoid confusion.

You can create project libraries from project folders. You also can convert LLBs to project libraries. LLBs have different features and advantages than project libraries, so consider the ways in which you might use an LLB before you decide whether to convert it to a project library. You can include project library files in an LLB.

If you include a palette file (.mnu) in a project library, you can set it as the default palette file for all VIs that the project library owns. The default palette file for a project library is the palette available in the shortcut menu when you right-click a sub-VI call to any VI that the project library owns, just as source palettes are available in the shortcut menus for many VIs and functions placed on the block diagram from the Functions palette. However, unlike source palettes, the default palette file for a project library does not have to contain any VIs from the project library it belongs to. From the General Settings page of the Project Library Properties dialog box, select the palette file in the Default Palette ring control. You also can set the default palette file from the Item Settings page. Select the .mnu file in the Contents tree and place a checkmark in the Default Palette checkbox.

Project libraries that LabVIEW deploys to the Shared Variable Engine (SVE) are called processes. Making changes to a process or to a shared variable within a process without affecting the corresponding library is known as online configuration. Making changes to a library or to a shared variable in a library without affecting the corresponding process is offline configuration. If you use offline configuration to change a shared variable, you must redeploy the library to the SVE before you run any VI within the library so the SVE can update the shared variable in the process.

Organizing Project Libraries

You can create an organizational structure for files that a LabVIEW project library owns. A well-organized structure for project library items can make it easier for you to use source control, avoid filename conflicts, and divide the project library into public and private access areas.

The following list describes some of the caveats and recommendations to consider when you organize project libraries and the files that the project libraries own.

• Create each project library within a separate LabVIEW project that contains only files related to that project library, including example files and the files you use to create and test the project library. Give the project and project library similar filenames. If a project library includes several separate areas of functionality, consider using project sublibraries for each area.
• Create a separate directory of files for each project library you create. You can include the files that the project library owns in the directory. If you include files for more than one project library in the same directory, conflicts might occur if you try to include VIs of the same name in different libraries. Organizing project library files into separate directories makes it easier to identify files related to specific project libraries on disk.
• You also can use a sort option to organize items within an unlocked project library.
• If you move files on disk that a project library owns, reopen and save the project library again to ensure that the project library links correctly to the moved items.
• (Windows) If you are building an installer that includes a project library, make sure you save the files that the project library owns on the same drive as the project library. If some files are on a different drive, such as a network drive, project library links will break if you include the project library in an installer.
• You can resolve conflicts between a library and the items claimed by a library by right-clicking a project root and selecting Find Items Incorrectly Claimed by a Library from the shortcut menu. Use this feature to find items that do not recognize a claim from a library.
• Determine which items in a project library you want to set as private and which as public. Users cannot use private VIs as subVIs in other VIs or applications. Public items provide the interface to the project library functionality and might include palette VIs, XControls, instrument drivers, and tools you want users to find and use. Private items might include support VIs, copyrighted files, or items you might want to edit later without taking the risk of breaking users' code. Consider the following recommendations.
  • Create a folder in the project library named private. From the Item Settings page of the Project Library Properties dialog box, configure the access settings as private for the folder. LabVIEW automatically sets as private any project library files you add to the private folder, so you do not have to configure access settings for individual VIs.
  • Assume that all project library files that are not in the private folder are public. You do not need to create a folder for public files.
  • You also can organize public and private items in a project library by creating folders for each functionality group within a project library and adding a private subfolder within each functionality group folder.

Project Sublibraries

Project sublibraries are project libraries that another project library owns. The settings in the owning project library do not affect access settings and editing permission for items within the project sublibrary. You can set the access of a project sublibrary file (.lvlib) as private within the owning project library, but when you edit the project sublibrary itself, items the sublibrary owns retain public or private access settings.

Project sublibraries are useful if you want to create a project library that includes separate areas of functionality. For example, if you are creating a project library of graphics tools, you might divide the two-dimensional and three-dimensional drawing tools into separate sublibraries.