Copying VIs under user.lib

[Norm Kirchner]

From what I recall and can see, is that VIs will look for their SubVIs at the relative location where they existed at the last time the calling VI was saved.

I'm messing around w/ VIs in user.lib and attempting to copy an entire user.lib directory elsewhere on disk (w/ some renaming and such)

But what I'm seeing in this situation is that the VIs copied from User.lib will not look for their SubVIs in their relative location first, but rather in their previous location in user.lib.

Assume for the sake of argument, that these baseline VIs must start out in user.lib.

Do you feel that the presence of a SubVI in userlib in a Top Level VI in userlib should not look relative first?

You can replicate this expanding the simple attached VIs into user.lib and then copying the directory elsewhere and then opening the top level vi.

I recognize this is a corner case, but am trying to see if anyone has encountered this issue before or if there is a better way of working around other than loading the vi hierarchy from their new location bottom up so that the callers see them in their new location first.

UserLibLink.zip

[Jim Kring]

Hey Norm,

This behavior is true for any links between LabVIEW files under a Symbolic Path, not just user.lib.

In order for a VI to "look relative" LabVIEW would need to know its own previous location under the symbolic -- does this information (it's own relative-to-symbolic path) exist in a VI that's saved under a symbolic path? For example, if I save a VI as "<user.lib>\Jim\MyVI.vi", does it persistently store information that it was last saved to "<user.lib>\Jim\MyVI.vi"?

[Daklu]

I recognize this is a corner case, but am trying to see if anyone has encountered this issue before or if there is a better way of working around other than loading the vi hierarchy from their new location bottom up so that the callers see them in their new location first.

I have encountered that before, but it was because I wasn't properly separating source code and distribution code. (Using user.lib as a source code dev directory != good idea.) Once I adopted better project organization practices the problem went away.

[Norm Kirchner]

I have encountered that before, but it was because I wasn't properly separating source code and distribution code. (Using user.lib as a source code dev directory != good idea.) Once I adopted better project organization practices the problem went away.

Understood, but at the same time, I'm looking for an appropriate single good place for a variety of tools and user.lib fits the bill, it just happens to be that this one thing (baseline template which requires 2 VIs and 1 Ctl) would have to have it's own special place just for itself which I still have not found an appropriate place for (which obviously can not be at a relative path)

[Kurt Friday]

Understood, but at the same time, I'm looking for an appropriate single good place for a variety of tools and user.lib fits the bill, it just happens to be that this one thing (baseline template which requires 2 VIs and 1 Ctl) would have to have it's own special place just for itself which I still have not found an appropriate place for (which obviously can not be at a relative path)

Hey Norm

A great tool I've found is the get and set linker info scripting methods. You could copy your subvi's to a new location and then run a utility that would look at the linkages of each vi, if the linkage points to a symbolic path but that vi exists within the folder hierarchy that you have copied to then update the linkage info to point to the correct or desired vi.

Edit

I couldn't help myself, I had to play with it.

The attached will re-link all your subvis contained within a directory, hence remove the linkage to symbolic paths. Doesn't handle LLB but it could be easily modified to do so

LVLinker.zip

[Ton Plomp]

I don't really see your problem but here are my thoughts:

You have a templateVI: ReadInstrument.vit, with a subVI StoreToDisk.vi

I can see two options:

1. Place the StoreToDisk.vi as a template inside the ReadInstrument.vit, if a new instance of the ReadInstrument.vit is invoked a duplicate of StoreToDisk.vit will be invoked. Dropping a template as a template inside a template can be done by dragging the Connector pane icon on the owning template.
2. Place StoreToDisk.vi inside user.lib, and place this inside ReadInstrument.vit, if a new instance of the ReadInstrument.vit is invoked StoreToDisk from user.lib will be loaded.

Why exactly do you want to copy something out of user.lib?

Another route might be is moving the user.lib branch, opening up the main VI, LabVIEW will miss the user.lib VIs and will look in subfolder of the main VI folder. After succesfully relinking the subVIs you can copy the branch back.

Ton

[Norm Kirchner]

I have encountered that before, but it was because I wasn't properly separating source code and distribution code. (Using user.lib as a source code dev directory != good idea.) Once I adopted better project organization practices the problem went away.

Daklu,

There is a bit of a different situation going on than as you're putting it.

I don't plan on having the user, use user.lib as a source code dev directory. I'm merely using it as a home for files that will be copied upon the start of a new *widget*.

Said widget directory, currently under user.lib, contains all files that will be copied and the new widget home will user.lib.

If you have a better recommendation for where a *Widget Directory* like this should be placed on a users system, I'm all ears.

Just keep in mind that it's just 3 simple stupid files that do not warrant a grand and esteemed unique location on disk.

But in actuality, I'm thinking that SciWare's trick is just what I was looking for.

So now, this *widget baseline* can remain at user.lib and I can start a new widget from baseline anywhere else on disk.

[Ton Plomp]

I don't plan on having the user, use user.lib as a source code dev directory. I'm merely using it as a home for files that will be copied upon the start of a new *widget*.

Said widget directory, currently under user.lib, contains all files that will be copied and the new widget home will user.lib.

So now, this *widget baseline* can remain at user.lib and I can start a new widget from baseline anywhere else on disk.

Well there is an official Templates folder under the LabVIEW folder.

Why not use that?

Ton

[Daklu]

I don't plan on having the user, use user.lib as a source code dev directory. I'm merely using it as a home for files that will be copied upon the start of a new *widget*.

I didn't mean to imply that you were. I made that comment mainly for newish LV users who might be wandering down the same path I did.

In the past I've wondered a bit about how to deal with the situation you're describing. The best solution I've come up with is to distribute the base widget code to two locations: user.lib for using it in vis directly and another directory that serves as a source for copying. I've also considered (but never experimented with) setting up file or directory links (forget what they're called) on the os level and having the vis in user.lib simply wrap the functions in the other directory. Unfortunately all these violate your original assumption so I didn't mention them.

SciWare's solution is definitely much more promising than anything I came up with. Kudos!

Edited July 22, 2009 by Daklu