You are here: NI Home > Support > Product Reference > Manuals > LabVIEW 8.2 Help

LabVIEW project libraries are collections of VIs, type definitions, shared variables, palette menu 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.

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 menu 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, double-click a project library file to open it in the 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. A project library might have a different organizational structure than its files on disk.

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 filename includes the filename and the owning project library filename.

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 filenames 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 non-LabVIEW file with multiple project libraries.

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 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.

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.

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 menu file (.mnu) in a project library, you can set it as the default palette menu for all VIs that the project library owns. After you select a default palette menu, you can right-click a subVI call to any VI that the project library owns and view the default palette for that subVI from the shortcut menu. From the General Settings page of the Project Library Properties dialog box, select the menu file in the Default Palette ring control. You also can set the default palette menu from the Item Settings page. Select the .mnu file in the Contents tree and place a checkmark in the Default Palette checkbox.

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. Each project sublibrary can include private and public access items and folders.