Do not load vi from a named folder

[Barionics]

Can I tell a LabVIEW project never to load VIs from a named folder?  I know that I can specify a folder to use in a search path, but can I specify a folder NEVER to use?

I keep having conflict problems, when I reuse VIs from project A in project B.  Then Project B does not know whether to load VIs from the project A folder or the Project B folder, so I try to fix the conflict errors, but there often seem to be conflict errors which just refuse to be fixed, leading to hours of headache.  Much better to just be able to tell Project B never to load Project A's VIs. 

[GerdW]

Hi Barionics,

some simple steps:

1. create a backup of project B

2. delete project B (or ZIP it…)

3. load project A and fix all errors

4. save project A

5. restore project B

Now repeat with A and B exchanged…

Why do you have conflicting errors at all?

And why don't you just revert to an older (and error free) version of your software with the version control system of your choice?

[RavensFan]

No direct option.

Here's a way to work around it.

Rename Project A folder to something else.

Load B.  Any files in B which link back to A will not be found.  Find the new VI's in B.  Save B project.

When you are done, go back and rename project A back to its original name.

[RavensFan]

Also, you are using the project explorer in LabVIEW aren't you?  Go to the file view option on the project window and it will point out where the files actually reside on the hard drive.

In general, you shouldn't have linkage problems if you are working on project A and Project B and they each are open in their own project environment.  But it is probably safer to only have one project or the other open at the same time.  When you are working on project B, made sure you don't go browsing to project A's file folder to get VI's.  Copy from A to B before you start opening them up in LabVIEW.

[JÞB]

A rigorous solution would be to to create a project template that contains a good portion of your expected conflist first.  then create your new projects from template.  Project templates script out copys of the template members and build the project from the new members.

Optionally, create a blank projectB. then Copy the project a members (Not librarys, it wont work with librarys since library members now what library they belong to) to a new location and add them to the new projectB from the explorer window.  Libraries  should be in a "Reuse location" and not necessarilly project specific

[Barionics]

Thanks for your help. To be honest these are the kind of practises I already follow, but I have wasted many hours over the years doing this sort of thing.

[Barionics]

I am now finding conflicts between VIs on C: and VIs on H:. Disconnecting H: and rebooting makes no difference, even when I do a recompile. 

[RavensFan]

Have you fixed the project so that the subVI's it is looking for are on c:\ and not h\?

Have you resaved those VI's?

[Barionics]

H: is dissconnected. I am doing a mass compile, which, I understand, opens and closes all the VIs one at a time. 

One technique which I have found sometimes helps, is to open a second, new project, and then temporarily shuffle the problem VIs into it. When I only have one conflict in the original project I can then, usually fix this. I then reintroduce the VIs one at a time, by dragging and dropping back from the new project, fixing conflicts as they appear. 

I am giving that a go now. 

[RavensFan]

Mass compiling might open and close them, but it isn't going to fix the links to broken subVI's

You need to fix the VI's that are either broken (because you've disconnected from the H:\drive), or if they are still cross-linked to a valid, but wrong location.

Then save those VI's.

Moving all of your files to a project and fixing the links as you find them is fine, but seems like more work than necessary.  As I said, the Files View in the project explorer will point out which files are being used and are in the wrong location.