Do not load vi from a named folder

[crossrulz]

Once you disconnect the H: drive, you could just look in the dependencies in your project.  You will see which VIs are missing, search to see who is calling them, and fix them to be looking at the right VI.

The other option is the Confict Fixer that is part of the project.

[JÞB]

---

@Barionics wrote:

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. 

---

That is a nasty problem! Of Course you are going to be in conflict trouble! A potential work around is to onpen the *.proj file in a text editor and replace all H: with C: then close and save it.  Start LabVIEW then open the project.  Moving code from one drive to another has to be done with care (and should be avoided).  Now, if H: is a network drive replace it with a SCC system!  If it is a mass storage device-Stop Doing That!  And keep "dependancies" clean!

[Ben]

Another approach would use Libraries instead of folders insid eht project.

Do a "Save As.." on the library and save it to where it will be stored for the new project.

Since Libraries pefix the library name when name mangling the VIs you have to go out of your way to crosslink libraries.

It can be thought of as "use the "Init" vie from this library" and not from any other named library.

Try it, you will like it.

Ben

[Bob_Schor]

---

@JÞB wrote:

---

And keep "dependancies" clean!

---

Amen!  I try to make it a practice, particularly when doing major changes, and especially when bring in "outside code", to examine the Dependencies before closing (and saving on Subversion) the Project and its files.  I've adopted the practice of having the entire Project be contained in a single folder -- if a VI is "shared" between Projects, it either needs to be in user.lib or a separate copy needs to be in each Project.  If I see anything in Dependencies (other than vi.lib, user.lib, etc.), then I know I have "work to do" ...

Bob Schor

[Ben]

Keeping dependencies clean is a good rule for simple applications that I follow as well. But for larger applications, multiple projects allow multiple developers to work with a minimal if inteferences. Developer A works on project A and Developer B works on project B that MAY call VIs from Project A.

In the case of develop B, none of the VIs that are in Project A are ever added to Project B but only appear in the dependancies.

Works great last a long time without runnin ginto conflicts.

Ben

[JÞB]

Ben, is that a purely one way association or can Project A call into ProjectB as well.  Either way if the reusable code was in a user.lib library you can expose only the API of the module and prevent the use of Core vis that are not properly abstracted by a pre-defined interface.  (Bonus- the exposed API is on the functions pallate and, dependancies stays "clean")

Of course, IF your development group were all "Super LabVIEW gurus" a few unwritten styles can be easilly tolerated.

[Ben]

If you can tolerate the tight coupling between the two - the two projects can call into each other. Please note though that if you use the VA hierarchy and use rounded corners for the lines in 2015 do not be surprised if labview crashes when you edit the relationships.

But if you stick with the straight lines connecting the libraries everything works fine. You may also see and on dotted line whenever recursion introduced.
Ben

[Barionics]

Thanks for all the good advice.

Where this all started is I took over a job from someone else.  He gave me his work as a pile of folders containing VIs.I don't know what half of these do and there is a lot of duplication.   I then put together a couple of Teststand sequences using some of these.   Now I am at the stage of trying to weed out all the duplicate VIs, but progress is slow and I often run into the kinds of problems covered here.