Introduction
Now that I have an outline design I want to set up the project so that it has a clear organisation. To do that I'm going to use a Project Library and Virtual Folders.
Table of Contents
Project Library
A Library is a useful means of organising related items, providing a namespace to qualify them in order to avoid any naming clashes with items that may be created by test applications that use the library. When a new item is created and given a name the library's name forms part of it (a qualifier) and this will distinguish it from other items in the project, but not the library, that have the same name. E.g. given a class called ResetCommand in library HAF, then the qualified name is actually HAF.ResetCommand (specifically: HAF.lvlib:ResetCommand.lvclass). This will ensure that any consuming application can contain an item that inadvertently (or otherwise) has the same name as a framework item without causing linking issues.
A library also allows me to set up access permissions for the contents of the library. For example, I can set public or private access rights to classes, or class methods, so that it is more obvious which ones should be used by a test application and prevent access to those that are wholly internal to the framework.
NI describes libraries in more detail in this article.
An additional feature of a library is its icon. In theory, according to NI, a library's icon is used as the basis for all the contained items which will 'inherit' it, and can add their own unique elements. I say in theory, because in practice it seems to only apply to VIs within the library and not classes which have their own icon (and subclasses don't inherit from their super class either.) It's a simple tool with drawing tools, colours, glyphs and text. Icons are sized at 32x32 pixels so are small and not very detailed: text looks a bit weird and I should think it's quite hard to create an icon that indicates a clear purpose.
Now, whilst classes don't inherit from their parent, it is possible to save a "partially completed" icon as a template. That way, the template can be used as a base for a new icon with additional information added for the specific purpose. That's pretty much what I would do anyway so it's not an issue.
Libraries are created under the project, can be nested and a project can contain many libraries. I'll be using just one and show how it is set up in the video:
Project Folder Structure
In a typical development scenario, the organisation of a project's files would occur through a number of folders on disk, e.g. \source; \bin; \libraries; \includes... With LabVIEW, there seem to be a number of possibilities and it can be confusing. Development interaction with a project is managed through the "Project Explorer" which displays the current project's organisation as either an "items" view or "Files" view:
| {gallery}LabVIEW's Project Explorer |
|---|
|
Project Explorer Items View: Shows the Project's items in a simplified structure. |
|
Project Explorer Files View: Shows the actual Project's files and folder structure. |
NI has this to say about managing applications using the Project Explorer. It discusses the use of folders for code organisation as a physical manifestation of the relationship between files and code in the application (as one typically does in other languages.) It's also very clear about managing projects and file locations through the Project Explorer so that the LabVIEW project can maintain the correct links across dependencies. In other words, don't move files manually on disk and hope that LabVIEW will recognise this when you next open the Project: it won't and you'll have to manually fix it.
From within LabVIEW, it is only possible to create a standard disk folder when saving a new item, e.g. a VI, using the OS save dialogue but there's no direct menu option. Creating it in this manner will show the new folder in the "Files" view. Any folder manually created outside Project Explorer, will not appear in the "Files" view, even if it resides inside a folder that does, until something is saved in it because, as mentioned, anything that happens outside LabVIEW isn't detected by the Project Explorer as there is no reference to it in the Project.
The document linked above discusses the use of Project Explorer for managing project organisation and with this it is possible to include an existing folder either as a "Folder (snapshot)" a.k.a. a Virtual Folder or a "Folder (Auto-Populating)":
- Virtual Folder: as the name suggests, it isn't actually a folder on disk, but a "construct" to allow items that are related to be kept together in the Items view. So it looks like a folder, but doesn't really exist on disk.
- Auto-Populating: this represents a more traditional folder on disk and LabVIEW will constantly monitor its contents and add them to the project. A Virtual Folder can be converted to an Auto-Populating folder which would then move all the items into that now existing disk folder from their current location.
More can be read about adding folders to a project in this "How-To" but I need to add some more about Virtual Folders because it can be quite confusing. It is possible with the Project Explorer to create a new Virtual Folder (for which a physical folder isn't created.) It is also possible to add a Folder (snapshot) for which a physical folder must exist for it to be added. When the "add Folder (snapshot)" option is used, a Virtual Folder is created in the project and any files within that snapshot folder also appear in the Virtual Folder as a one-time action. there is no actual link between the virtual folder and snapshotted folder: any items created within that virtual folder can be saved outside of the disk folder unless you specifically navigate to it as part of the save action. It can get quite confusing really!
Scanning the forums, more experienced LabVIEW developers seem to be mixed on the use of Auto-Populating folders. Some decry their use totally, others swear by them. I don't know what the right answer is right now as I'm not experienced enough to make that decision. However, Auto-Populating folders are not recommended when managing project libraries or classes and won't work for project templates. That makes it an easy decision for me to stick with Virtual Folders, for this project, and, when deemed necessary, a standard folder somewhere within the project's root folder.
I will create these Virtual Folders as a mapping to the Package objects I created in the UML model and not worry too much about disk storage structure. This follows on the tail of experienced described in this post.
Final Virtual Folder Structure
Actually, this is a final-ish structure: it evolved during development with additional sub-virtual folders and as the package structure changed: this is a more final structure:
Summary
- Libraries are a useful organisational mechanism for related items.
- Create an icon and save it as a template to use as a common base for Library items and Classes. It can be built on to create a more specific icon for any item.
- Use Virtual Folders to organise items within a project independently of how they are stored on disk.
- Use actual folders on disk to save items independently of Virtual Folders where this matters.
- Use a Snapshot Folder to bring existing items into the project on a one-off basis. The folder will be represented as a Virtual Folder within the project and managed independently of the physical folder
- Use an Auto-Populating Folder to bring existing and any future items created outside the LabVIEW project into the project.
- It is not possible to use Auto-Populating Folders inside a Library or for Classes.
- Don't use Auto-Populating Folders for any project destined to be used as a Project Template.
Next: Anatomy of a Class
