What's in a Name? (Libraries)

I want to come back to the topic of cross-linking. LabVIEW 8.0 introduced a feature that is very useful for avoiding cross-linking: project libraries.

It's a slightly misleading name. You don't need to use LabVIEW projects (also new in 8.0) in order to use project libraries. And although LLBs were often referred to as libraries in the past, project libraries have nothing to do with LLBs. (Except that you can put libraries in LLBs... confused yet?)

Most of the time, I just use the term libraries instead of project libraries, and that's what I'll do for the rest of this post.

I've had several people tell me that NI presents new LabVIEW features in terms of what they do, rather than what they're for. So I want to spend a moment to talk about why you might want to use libraries.

The primary intended purpose of libraries is to help you group VIs. There are numerous reasons why you might want to group VIs:

• shared components
• toolkits
• versioning
• etc.

Generally, these groups consist of VIs that you want to call from outside the group (i.e. the interface) and some supporting subVIs.

In the past, you had few options when you wanted to designate the interface VIs:

• put them in a higher folder
• mark them as top-level in an LLB, or
• give them special names.

There was no way to prevent someone from calling your support VIs directly, though. That meant as soon as you shared your VIs, you had to be careful about changing the connector pane of your support VIs, because caller VIs would break if you did so, and you had no way of knowing who those might be.

Putting a group of VIs in a library conveys numerous benefits, including:

• Namespacing. The name of a VI in a library is a combination of its file name and the library name (e.g. MyLibrary::MyVI.vi). This lets you use simple VI names (e.g. Add.vi) without cross-linking (assuming your library names are unique).
• Public/private access scope. Private access scope means that only VIs inside the library can call the VI. Now you can change your subVI connector panes and know for certain that you only have to fix caller VIs inside the library.

OK, so now let's talk more about the technical details. The library (*.lvlib) is not a container file. It is its own kind of LabVIEW document, independent from its member VIs. A VI can be a member of one (and only one) library, but libraries can be members of other libraries.

The library knows which VIs are members of it, and a VI knows which library it is a member of.

If you think about this in terms of VI linkages, you'll notice that this caused a significant change to LabVIEW. Prior to libraries, VIs and subVIs formed a tree of linkages. (SubVIs do not record the VIs that call them). But library/VI linkages go both ways, so linkages no longer form a tree. Instead, they form a graph. This is why, when you save an Untitled library and Untitled VI in it, we have to ask you for the names of both before we can save either.

The namespacing ability of libraries is an extremely powerful tool in avoiding cross-linking. Anytime you make a copy of your VIs, add the copies to a new, uniquely-named library and you'll be certain that you won't accidentally link to them in the future.