Feature Request: Make <labview> a Symbolic Path

[Jim Kring]

When a LabVIEW file (VI, CTL, LVProj, LVClass, etc) links to a file that is located beneath a Symbolic Path, LabVIEW stores the link as a path relative to the symbolic path. However, there are several folders beneath LabVIEW, which should definitely be, but are not, symbolic paths.

For example:

./resource/

./examples/

./help/

./project/

I would like to make the following request of NI...

Please make <labview> (or <application>) a symbolic path. Any file located beneath the LabVIEW installation root, which is not in a more specific (deeper) symbolic path, should be linked to, relative to the LabVIEW installation root.

:2cents:

-Jim

[update: This has been sent to NI, via the Product Suggestion Center]

[Yair]

Agreed, that would definitely be nice. It might also be nice to have user defined logical folders, but I can see how that can be a problem when moving between computers.

[Ton Plomp]

QUOTE(Yen @ Oct 20 2007, 07:10 PM)

Agreed, that would definitely be nice. It might also be nice to have user defined logical folders, but I can see how that can be a problem when moving between computers.

Well there are 2, the LabVIEW data folder which by default links to 'My Documents\LabVIEW Data'

And the Temp directory which by default links to the OS Temp folder:

And there's the default folder which points by default points to the LabVIEW folder (but it can be changed):

The problem is that these paths are not symbolic

Ton

[Aristos Queue]

I won't get involved with the discussion about more symbolic paths to LV built-in stuff. Technical pros, technical cons, politics, blah, blah, blah...

But as far as user-defined paths are concerned, there's a number of technical blocks to with having arbitrary definitions for symbolic paths as they're used on the internals of LV. But I could see someone creating a set of VIs that managed a path translation scheme for loading VIs dynamically from user-defined symbolic paths. Might be useful for one of you to put together.

[Yair]

QUOTE(Aristos Queue @ Oct 21 2007, 03:31 PM)

But I could see someone creating a set of VIs that managed a path translation scheme for loading VIs dynamically from user-defined symbolic paths. Might be useful for one of you to put together.

I believe OpenG already has quite a few VIs which deal with relative paths, even if not with symbolic paths. I'm sure extending them would not be impossible. The problem here is that statically linked VIs are much easier to work with than dynamic ones, and for that you need the internal LV linker.

[Rolf Kalbermatter]

QUOTE(Yen @ Oct 21 2007, 04:01 PM)

I believe OpenG already has quite a few VIs which deal with relative paths, even if not with symbolic paths. I'm sure extending them would not be impossible. The problem here is that statically linked VIs are much easier to work with than dynamic ones, and for that you need the internal LV linker.

Actually the OpenG Builder and also the OpenG Commander (and quite likely VIPM as it uses for quite some part still the same VI libraries) does have VIs supporting symbolic paths. I created them back in the early days of OpenG Builder together with the lvzip library to support a flexible package installation system, that the ogp files are still mostly based upon. For the Commander they reside in OGPM PATH Convert Keyword.vi, OGPM PATH Keyword Expand.vi and OGPM Keyword Manager.vi.

QUOTE(Aristos Queue @ Oct 21 2007, 08:31 AM)

I won't get involved with the discussion about more symbolic paths to

LV

built-in stuff. Technical pros, technical cons, politics, blah, blah, blah...But as far as user-defined paths are concerned, there's a number of technical blocks to with having arbitrary definitions for symbolic paths as they're used on the internals of

LV

. But I could see someone creating a set of VIs that managed a path translation scheme for loading VIs dynamically from user-defined symbolic paths. Might be useful for one of you to put together.

Only problem with that is that it would not pertain to the paths stored in VIs itself and to loading them as that requires access to LabVIEW interna that can not be dealt with with "App:Read/Write Linker Info from File" afaik.

Rolf Kalbermatter