Make libraries and VIs less environment aware

[Miha_Vitorovic]

I just downloaded a library and a project it was developed in. I tested it, and everything works fine. Then I copied the library (.lvlib, all .vi files and preserving folder structure) to a new project, but when I open it I get a conflict saying that the same library is defined twice? A conflict that cannot be resolved BTW.

I spent 30 minutes just getting out of the mess this puts me in. The result, project2 is now OK, but project1 now complains that it has duplicate code. Come on! I know I have two copies of the same library! I want to have two copies of the same library! Why can't LabView just use the "local" version and not complicate my life with something that happens to lie on the disk somewhere and has absolutely no connection to the current project?

[Intaris]

Maybe because it DOES have a connection to the project.....

Problem might be home-made?

[Miha_Vitorovic]

I opened the lvlib file in the text editor to find any absolute link. I couldn't find one.

Also, I didn't modify files in the original (library) project in any way, but when I open that project it says that it is in conflict with the newer (my) project. So, even if there was some hidden direct link from the copy to the original, there should be no link from the original to the copy. Right?

[Miha_Vitorovic]

Thank you for the verbose description of what I could be doing wrong. But it doesn't describe my problem, because in the step where I copied the lvlib and vi files I used "OS copy", not the "LV save as". Then in the second project I used "Add/File..." and pointed to both .lvlib files.

When I find the time one of these days I will try to recreate the problem using a fresh version of the same library and record the steps on the way. If I get the same error, I will post the recipe here.

[AristosQueue (NI)]

> Then in the second project I used "Add/File..." and pointed to both .lvlib files.

You tried to put both library files in the same project. That *is* the conflict. You can only use one file of any given name in a single project. Then when you untangled, I bet you got some VIs originally from library A pointing at library B and vice versa, leading to modifications of the original.

[Miha_Vitorovic]

I'm sorry I wasn't more clear in my orginal post. The original project contains 2 libraries. I will create a "walkthrough" and see if it takes me to the same problem. Anyhow, I have a feeling that should a problem arise one more time I better take this through the normal support channels and not litter this forum with it, since it is obviously a bug of some sort (but we will have to see if it is a user bug or a product one :))

[TCPlomp]

I think I may have experienced the same issue.

And I think I found the reason:

1: Create an lvlib inside vi.lib\foo\bar.lvlib

2: Create a VI vi.lib\foo\zeta.vi

3: Add the VI to the lvlib

4: Copy the foo folder out of vi.lib to a folder fooclean

5: Create a new project fooclean\foo.lvproj

6: Add bar.lvlib to the foo.lvproj

7: LabVIEW will generate warnings

I investigated this and openend the bar.lvlib with a text editor. It turns out that the library has absolute paths to the files inside vi.lib, not relative paths too ..\zeta.vi as I would expect.

The other part of the problem is that zeta.vi has a relative link to bar.lvlib (as far as I can understand).

So at the end of the test:

-fooclean\bar.lvlib points to <vi.lib>\foo\zeta.vi

-<vi.lib>\foo\zeta.vi points to <vi.lib>\foo\bar.lvlib

I conclude that it's a bug inside the project/lvlib/xcontrol/lvclass environment that a path inside vi.lib is always stored as an absolute path while it might be better  to use a relative path.

Ton

[AristosQueue (NI)]

> I conclude that it's a bug inside the project/lvlib/xcontrol/lvclass environment that a

> path inside vi.lib is always stored as an absolute path while it might be better  to use a relative path.

Since time immemorial (which translates as "before I started working on LV in version 6.0"), a VI records the paths of its subVIs as relative paths unless those VIs are inside vi.lib or instr.lib. The "psuedopaths" are not absolute paths. They are pseudopaths because they go to whereever vi.lib happens to be located at the moment. When a subVI inside vi.lib is missing, there are different rules that apply for searching for the missing file than for other missing subVIs. This allows VIs to have target specific implementations and a VI will load the correct subVI for the target when it loads into memory. So, for example, you have

<vilib>\Utility\error.llb\Simple Error Handler.vi

When loading on the desktop, that pseudopath resolves to

<labview>\vi.lib\Utility\error.llb\Simple Error Handler.vi

But if the caller VI is loaded into an FPGA target, that pseudopath resolves to

<labview>\vi.lib\FPGA\Utility\error.llb\Simple Error Handler.vi

Libraries follow the same rules that VIs always have -- paths inside vi.lib and instr.lib are absolute, paths outside of those directories are relative.

There are other special cases for resolving pseudopaths. Mostly these are not a problem since the items inside these directories are generally finished code that is not directly modified. But you are trying to create a copy that you can modify. You'll need to use Save As to copy the files out of vi.lib because -- as you noticed -- copying on disk results in a copy that still points back into vi.lib.

[G-Money]

Programming issue. Naming conflicts.