moving files and reassigning paths in project

[bracker]

If I move my VIs into different directories for housekeeping purposes, then I need to inform my projects where the VIs are.  What is the most efficient way to help my projects find the new locations of the VIs?  I've been playing around with autopopulating folders and moving things directly from a Windows Explorer, but in both cases, the Project Explorer needs to be told file-by-file where the files have gone.  I'm hoping I can avoid that.

[Justin_P]

Hello,

Currently this is the way that it is done.  If you have any ideas on making this process better please let us know by posting to the idea exchange.

[Ben]

You could use a "Tree.VI" along with a Source Distribution to accomplish this.

The issue is that the path of the sub-VI is stored in the VI along with the project. To change the paths you have to make usre the callers as well as the project know ehre the files are.

Create  tree.vi that holds the top-level VIs.

Creae a source distribution and configure it to preserve hiarchy and save to new location. When built every thing will be picked-up moved and re-linked.

Next trick to exloit LV.

If you plan to use that colection in a project, add the tree to your projec then open it to force LV to load those VI from where the tree thinks they should be. THEN open other stuff. This exploit the rule that LV will only load one VI of a particular name at a time. If it attempt to open another it will skip the other since it is already loaded.

Ben

[bracker]

Darren, thanks.  I think your solution is a bit over my head, at least the discussion in Greg McKaskle's post.  But I can grasp some of the ideas you suggest--I think "Create a source distribution and configure it to preserve hierarchy and save to new location. When built every thing will be picked-up moved and re-linked," will come in handy somehow.

By the way, is this "tree.vi" thing a real VI somewhere?  I didn't find it among the posts you linked to.

I may post a suggestion on this topic at the idea exchange, but to be honest, I'm fairly new to Labview, and I need to do more homework to really understand the capabilities and limitations of project & file manipulation in Labview.  I'll probably ask a few more question as I go along, but not right now.

[bracker]

Sorry Ben, I didn't mean to call you Darren.

[Ben]

Tree.VI Catalog.VI, Root.VI are synonyms for a VI that is never intended to run but contains all top level VI used in an application. It serves as programming aid that allow loading everything by just opening a sinlge VI.

In house I enforce an additional requirement (for my fellow wire-workers) that the Tree.VI should always be saved as non-broken. Not to imply the Tree could be run (bad thing can happen when I accidently try running the Tree!) but it serve as a quick check of all of the code and tells me that there are no broken VIs anywhere. It also helps with dynamically loaded VIs to enusre they "know" about code update that could affect them (like type def changes).

SO in-house rules for the Tree

All top level VIs in the Tree

Tree should not be broken

Never push updates to the server that break the tree

Always code with the tree open

Ben