This post was originally published at Walking the Wires
When I started solving problems using LabVIEW, my programs were usually very small. Back then, we didn’t even have the project explorer, so organization on disk was very important. It was very common to have a folder called Controls, another folder called subVIs, and the Main.vi on the root folder for the project.
I still remember there was a lot of resistance when the Project Explorer was introduced. A lot of seasoned LabVIEW developers didn’t see the need for an organizer. It was particularly confusing that the folders did not reflect the organization directly on disk. This has changed over the years and now we have auto-populating folders and virtual folders, the project window itself has had a couple of upgrades to provide us as developers with a more useful overview of our program. We also have Project Libraries (not to be confused with llb libraries) and LabVIEW Classes as well.
The more I used the project, the project libraries and the classes, the less sense it made to have a folder called Controls and another folder called SubVIs. I started to organize files in my project explorer and in the project libraries without much concern on what was happening on disk.
The folder structure that I advocate today is the one in the image below. I set the project explorer to show the path so you can see how, despite all the organization via virtual folders on the left, everything is saved flat in the library folder. This makes it easier to move folders around without losing the linkage to some of their parts.
You may also notice another idiosyncrasy that I picked from Justin Goeres several years ago: All my controls have a “–” as part of their name, identifying what type they are. For example states–enum.ctl. This has several advantages. For example, if you are a Quick Drop enthusiast, you will be able to just type –enum and get a list of all the *–enum.ctl. Chances are that you will find the enum you are looking for, since Quick Drop not only lists items in the palettes, it also lists items in your project. For some projects, there are multiple controls with very similar names, such as Instrument settings–cluster.ctl, which in turn includes Instrument modes–enum.ctl. When you come back to work on the project after months of being away, the little — tag can make it easier to find what you are looking for.
Curious about what the project below is doing? stay tuned and you will get a chance to play with it when the Delacor QMH comes out!
Oh! and one more thing, please ensure that the Dependencies section of your project only has vi.lib and user.lib references. Everything else should be part of your project, unless you like to relive old times when LabVIEW would load a forgotten copy of a VI that had the same name and you would spend hours troubleshooting 😉