Basics of LabVIEW project management

[JKSH]

Hi all,

I'm new to LabVIEW, coming from a C++ background.  I'm curious about an .lvproj behaviour -- I'm allowed to have a subVI as an external Dependency, without including it in the project itself.

What's the basis of this design?

If I understand correctly, an .lvproj is intended for managing the files that are part of an application (or set of related applications). My immediate thought, then, is that the sensible thing to do is to have ALL relevant files tracked by the .lvproj -- with the exception of libraries, which are being used by the project (as opposed to being developed within the project).

What are the use cases where a VI should remain a Dependency, and not a Project component?

Thanks in advance!

[BillMe]

I look at it from the point of view of distributing the project to someone else to run, debug and/or compile into an application on another machine. Everything they need to successfully do that is included in my project with the exception of OS system level binaries, e.g., Windows DLL's and the LabVIEW vi.lib since those are in common between the machines. I also include any and all pertinent documentation in my project.

[JKSH]

Thanks for your explanation, Bill. If I've understood you correctly, it's good practice to have the .lvproj contain all files required to run the application (minus ubiquitous system files), and all relevant documentation regarding the application.

Back to my original question, then: Why does LabVIEW permit me to run and build the application, even when I forgot to place some required files (e.g. subVIs) in the .lvproj? I guess it's a convenient feature, but it seems somewhat counterintuitive -- if I were to use an .lvproj to manage a project, I might as well go the whole way (and have LabVIEW warn me if I forget to include something).

I was wondering, if there are any use cases where I would want to keep files OUT of my .lvproj?

Not a critical question, just curious 🙂

[Norbert_B]

Having custom written components in the dependency list is not suggested. I recommend to manage them explicitly in the project explorer (following a comparable setup to the folder hierarchy on disk).

That being said, i'll answer your question:

When opening a LV VI, it will automatically load the static VI hierarchie into memory. So all subVIs are usually loaded into memory at this point.

If a VI with the same name (but openend from a different folder location) is already in memory, you will get a conflict which might introduce project crosslinkings.

The project populates the dependency list automatically with all loaded files within the projects context, which are not already covered in an explicit way.

So both approaches (explicit vs. implicit management) work in the development environment, but implicit management (all having in the dependency list) removes certain (important) options for building applications/installers/source distributions.

hope this helps,

Norbert

[JKSH]

Thank you for your insight into the VI loading mechanism, Norbert. It helped me understand LabVIEW's internals better.

Yes, I intend to use explicit management, which is in line with my experience with Visual Studio projects and Qt projects. Those frameworks require explicit management, so I was curious about the flexibility/leniency of LabVIEW's Project Explorer.

But actually, I just realized I've been thinking about it the wrong way: It's not that Project Explorer is lenient; rather, it has a good feature to help developers identify items that they may have forgotten to explicitly add to the project.