Quick and dirty way for optional dependency in source code?

[ensegre]

So here is my situation: I have this software I'm providing since years, which depends, for a nice side functionality, on a toolbox which the end user might have cared to install or not. (Show of hands, some static copy of LuaVIEW, in a local or in a system directory, or through VIPM). I used to distribute this software as source, just zip of vis and llb, because after all it's for internal use, and may happen to be debugged on target. Not even cared to create once for good a proper project for it, it just grew on like that.

 

Now it occurs to me, it could be sensible to check at runtime for the presence of LuaVIEW, and to disable the additional features if that is not found. Not found, presently, just means that some subVIs on the main BD are missing or broken. I figure that it would be rather easy to check dynamically for a Bad status of some VI wrapping a LuaVIEW subVI, and use that as a flag.

The best approximation to what I need, which I could think at, would be to wrap those broken part in a conditional disable structure. But, stock CD structures in the IDE can be conditioned only by bitness/targer/RTE, not by some runtime value (and it makes sense they can't; it's about compilation). Another option coming to mind, would be to create a project for good, with conditional disable symbols, and two different builds depending/independent, but then should I distribute only the builds?

 

Other options coming to mind look to me more cumbersome. e.g., I don't know, calling all relevant LuaVIEW vis dynamically, thus having them not explicitly on main BD. Or, I suppose plugin library may be the keyword, but then do I have to transform LuaVIEW in a plugin, which is above my head and not my call? Any elegant suggestion?

[ShaunR]

This was a problem for me too.cThere is no elegant solution that I know of.

 

You either architect your software to call dynamically the functions you need (plugin architecture) which works great in classic Labview where nothing is broken but you are stuffed if you use classes.

 

Then, as you describe, the conditional disable. This is the only alternative I have found so far (open to more ideas) that works for everything but has some caveats (like the dependency has to be installed first so upgrades are difficult). I just put the onus on the developer/user to add a conditional disable tag into their project which also has the side effect of allowing them to choose whether to ship with that feature or not if they do have it (toolkits, obviously). The default shipped state is the plugin is disabled and they add the tag when they enable it which will either activate the feature if it is installed or break their VIs.

[CraigC]

I believe you can edit the custom symbols found in the project / application. found here

 

http://forums.ni.com/t5/LabVIEW/Programmatic-read-access-to-project-symbols/td-p/505952

 

Thus it might be possible to launch via a splash  screen and set this symbol if the plugin is found? Just a though

 

Craig

[ensegre]

Yes, this way seems to be reasonably simple and have potential. It looks that symbols of an open project can even be changed on the fly, thus the symbol-setting VI can be part of the same project; the only nuisance is that VIs and project will appear as changed and unsaved.

 

Here is my first attempt at it (LV15); I have still to figure out what could be the leanest way for the end user.

 

 

TestDependencyChecker.zip