LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
dmafackler

Enable LabVIEW project to specify VI search path...

Status: New

Idea reopened now that LabVIEW NXG has been discontinued.

Enable LVPROJ to specify VI search path.

  • A "path" may override or be composited with the path specified in its parent environment (the IDE or another project).
  • A "path element" may be a directory or file, or a recognized LabVIEW type (lvproj, lvclass, lvlib, virtual folder, etc.) that can be resolved to a working environment directory or file.
  • A "path element" that resolves to a directory may be searched at just the top-level or it may be recursively searched.

If no project search path is specified, default to current VI resolution behavior.

 

If a project search path is specified, resolve VIs by name within the scope of that path. If resolution fails and parent scope is available (composition rather than override), search the parent scope too.


Straw use

Given ProductA dependent on, but not containing CommonLib. When CommonLib moves for arbitrary reasons, the developer shouldn't have to (tediously) reconnect each individual component referenced. It should suffice to modify ProjectA's VI search path to reflect CommonLib's unique and perhaps relative path location. Perhaps, the "Find the VI" dialog should sport an option to modify the VI search path as an alternative to specifying the precise VI.

 

If I'm revising a product to use Library 2, I want to be able to checkout the product based on Library 1 and then re-point the project search path to pick up VIs from Library 2. A VI should resolve in the scope (possibly upward recursive) of the project search path. If that fails, then it should prompt--relative or absolute pathing within the VI should have no precedence when project search path is specified.

5 Comments
Darren
Proven Zealot
Status changed to: In Development
 
Darren
Proven Zealot
Status changed to: Completed

Available in LabVIEW NXG 1.0. A project will only link to libraries based on installed packages, or components that are currently added to the project.

Quiztus2
Active Participant

Can we have this idea reopened?

Actor Framework
Darren
Proven Zealot
Status changed to: New

Idea reopened now that LabVIEW NXG has been discontinued.

Quiztus2
Active Participant

I'd like to add to this idea that it might be necessary for VIs to be able to forget the absolute paths to subVIs. Otherwise, the aforementioned CommonLib might open VIs that are present on the machine, but not the ones intended for this project. The goal must be to ensure that copies of the same CommonLib can be used selectively. Otherwise, tools like git submodules become difficult to use.

Actor Framework