labview 2011 forgets new dependency path

[dlanger]

Since I switched from LV 2010 to LV2011 I have been repeatedly encountering problems with LabVIEW forgetting a modified path of a dependency (e.g. a DLL or a LVOOP class).

Example: I had a LVOOP class A that I was using inside another class B (as an attribute). When I was cleaning up things I decided to to move this dependency class A to another directory. When opening the LV project for class B, LV could not find class A anymore, the usual search dialog popped up. I showed LV the new location of class B using the dialog's browse button. After loading of the project, LV displayed a warning dialog indicating that class B had been loaded from a new position. I saved the project, but when loading it the next time, LV was again searching for class B; obviously it hadn't saved the new path of the class. The procedure can be repeated ad infinitum, LV always forgets the new path.

Question: Is there any cure for this nasty behaviour? I never had such problems with LV 2010...

[jkuttu]

Hi dlanger,

                Me also confronted with the same problem.while switching from two LV versions.

[JÞB]

Is this on Windows?

What DLL?

[dlanger]

The problem encountered with the DLL is described here:

http://forums.jki.net/topic/1948-wrong-path-for-dll-with-net-assembly/

I am starting to believe that the problem is one of LV 2011 itself and not of the JKI package manager...

[SofiaShahid]

I am using labVIEW 2012 and when I change the file path it does not update it and I am getting this warning dependency loaded from new path. Evethough I am working with the same LV version.

[RTSLVU]

LV2012 seems to forget every new dependancy path.

I have several projects that I update everytime I open them.

I can update a project, save it close it, open it and I have to update it again.

Why can't LV write this down someplace to remember?

Actually I am guessing there is some file permissions problem with whatever file this data is stored and changes are not rerally being saved.

[Bouddi]

I am also having same issue with LV2013. Any solutions yet?

[JÞB]

This type of issue is most frequently encountered when you use windows explorer to move a vi on disc and forget that the project explorer has a files view.  Use the files view in the project explorer and the right-click option to "Move on disk" and the project explorer will prompt you to save effected callers.

[Bouddi]

Hi Jeff,

Thanks for that. Now I know I have to be careful whenever I change the file locations.

Steve

[JÞB]

---

@Bouddi wrote:

Hi Jeff,

Thanks for that. Now I know I have to be careful whenever I change the file locations.

Steve

---

---

No trouble at all (Glad too help)

The project remembers the members dependancies.  (That almost rolls of the tounge right?)  The memebers are not in memory unless the are open within  the project context.  Moving sub vis without using the project explorer file view is a good way to cause yourself pain.  It is exactly like putting a book back on A NEW library shelf without updating the book's card catalog entery... you need a conflict manager to find it again! Moving sub-vis from the RCM in the project explorer's files view triggers the librarian to go and update all callers (Windows couldn't know who calls what right?)  Some VI server properties need to be called "Under-the-hood"  Project explorer does that for you to make your hair last longer.