Make the LabVIEW "resource" folder a symbolic path

[Jim_Kring]

There are many VIs located beneath the "<LabVIEW>\resource" folder that need to be called as subVIs of LabVIEW add-ons (e.g. project providers need to call provider API VIs located there).  However, because the resource folder is not a Symbolic Path this introduces many challenges for LabVIEW add-on developers.  LabVIEW add-ons that link to VIs beneath the resource folder cannot be moved to a new location (for example as part of a source distribution build step), otherwise they will not be able to find these resource subVIs (since they link via a relative path between the caller and subVI, rather than a relative path between the resource folder and the subVI).  Note that NI doesn't really feel this "pain" since most of the add-ons NI develops are developed "in place" beneath LabVIEW and ship with LabVIEW -- they don't get "built" and they don't get "installed".  However, for 3rd party add-on developers, it's critical that the resource folder be a symbolic path.

Note: This would make building packages of project provider plug-ins possible with VIPM.

[Jim_Kring]

Note that I posted something similar to this on LAVA a while back: http://lavag.org/topic/6368-feature-request-make-a-symbolic-path/

[TCPlomp]

Wouldn't it be better to make the 'LabVIEW' folder a symbolic path?

This could off course be dangerous since the same file can resolve to different symbolic paths:

<labview>/vi.lib/start.vi equals <vi.lib>/start.vi

[crelf]

Wonky? Is that a technical term? 🙂

[GregR]

I have probably been the lone obstacle to this for many years. The reason I have resisted is to try to hang onto some distinction between editor dependencies and runtime dependencies. The idea is that VIs that can only be used in a development environment belong in resource. VIs that could be referenced from user VIs and therefore deployed into built applications belong in vi.lib. This forced us to think about expansion of runtime dependencies. There are 2 things that have made this less effective in more recent years. First, the public release of scripting meant more exposure of editor-only functionality to user VIs. Second, the expanded publication of ways for users to plug into the development environment. These both make the editor/runtime division no longer line up with the referenced/not referenced from user VIs division. We either have to move a lot more stuff in vi.lib or we have to introduce a second location. If we need a second location, resource probably makes sense.

[StephenB]

If you're building an app, the dependencies get automatically included into the app anyway and don't link to VIs in vi.lib... so I don't understand why this is related. Could be missing something obvious...

Also, when I build VIs that need to be dynamically called by an app, I always bundle them into LLBs that have all their dependencies included... so there is no LabVIEW dir interaction there either.

The most common VIs I use in resource are the rvi ones (lv fpga)

[Jim_Kring]

Hey, GregR.  Thanks for the comments.  I'm happy we have the "right guy" in the discussion 🙂

I see that you've also responded to the related thread I started in the LabVIEW Add-on Dev Center.  I'll probably focus on responding in that thread, since the discussion forums there are a little more user friendly and we seem to have a good dialog going with a lot of people.

Thanks,

[Jim_Kring]

@crelf no, "wonky" is just regular word 😉

[Darren]

Available in LabVIEW 2012 and later