How do I determine VI file specification in Executable?

[Matt_W1]

Assuming your plugin system works by listing plugin's external to the application as paths (basically a vi that returns an array of all the path's to the plugin vis that aren't in the exe). Then to add the internal plugins you just need to concat an array of valid internal paths onto the external array, then as far as the plugin system is concerned there is no difference between internal and external. The simplest way to produce the internal array is to have an array of static references to the internal plugin vis, then get the vi path from those references. An advantage of this is you don't need to add the vis to the always include list of the build settings since the static reference includes them implicitly (the static reference doesn't necessarily include the front panel so you can use always include to work around that). The disadvantage is that all the internal plugins are always in memory.

[ww.brown]

I am trying to avoid use of static references.  I don't want my code to recompile everytime a new version of a plug-in is added.  I have no problem adding the new plug-in instance as "always included" at build time.  All I need is the new internal path to the VI.

LabVIEW 2009 let you do this using OpenG zip library functions.  That option is now gone.  I am just wondering what 2010 technique is now used to gain access to the same information.

WB

[Been bitten by LabVIEW]

Then don't.  Make a directory for your plugins and dump them all in there.  If you are worried about some having the same name, then write a wrapper vi around them and put the wrapper in the plugin directory.

I might be wrong, but if you add a VI, don't you have to recompile anyway?

A

[blawson]

are the different versions of your plugins different files?

also, I don't think that changing a statically referenced VI causes a recompile of the caller: a broken referenced VI does not break VIs that reference it.

[ww.brown]

I have several options including static VI references.  I have demonstrated that having the builder copy everything into the \data directory will also work.

As I mentioned earlier, my application is configuration file driven.  My users want to be able to specify a plug-in VI in a configuration file, then add the plug-in VI to the LV project “always included” directory and re-build the executable.  They don’t want to alter source code with a new static VI reference.  With these requirements, having the builder copy everything to the \data directory is an acceptable workaround.  Since this may involve a large number of source files, I was just wondering how to build everything into the executable as an economy.

I am curious why this capability was allowed in LV 8.6 and LV 2009 and is no longer allowed.  It seems pointless to offer the VI in executable option without providing a technique for getting the resulting VI specification (see 11-23-2010 02:19 PM on this thread for more).

WB

[Matt_W1]

You can make plugins that can be compiled separately from the main system, then you don't even need to recompile the main executable.

The always include option makes sure the front panel isn't stripped away in the executable, which can be useful if you're call vi's by reference. It's also useful if you load a plugin that calls those VI's but your main doesn't.

[ww.brown]

Thanks Matt.  I will look into the separate compile option.  I have not tried this before.  Have you a link to docs?

[Matt_W1]

This might help point you in the right direction.

http://expressionflow.com/2008/06/02/extending-labview-built-applications-with-lvoop-plugins/

I made a proof of concept using packed libraries yesterday (the key trick was making the interface it's own packed library). It seems to work, but there may be some limitations I'm unaware of.

[blawson]

---

wwwbrown wrote:

I have several options including static VI references.  I have demonstrated that having the builder copy everything into the \data directory will also work.

As I mentioned earlier, my application is configuration file driven.  My users want to be able to specify a plug-in VI in a configuration file, then add the plug-in VI to the LV project “always included” directory and re-build the executable.  They don’t want to alter source code with a new static VI reference.  With these requirements, having the builder copy everything to the \data directory is an acceptable workaround.  Since this may involve a large number of source files, I was just wondering how to build everything into the executable as an economy.

---

ah, ok. So the final built executable winds up only having the configured plugin components built in, even though your preparation generally covers all of the possible plugins.

If you built them all into the exe, it's no longer a plugin but a list of built-ins, and it should be easy to case them all out.  If you have a configuration-driven build, you could still have every component's path hard coded in path constants inside a case structure, even if not all of them get built in.

---

I am curious why this capability was allowed in LV 8.6 and LV 2009 and is no longer allowed.  It seems pointless to offer the VI in executable option without providing a technique for getting the resulting VI specification (see 11-23-2010 02:19 PM on this thread for more).

WB

---

It's a pain, isn't it? Alledgedly part of the requirements for certifying for Vista and Win7 is that an executable's components may not be externally accessibly (at least without an API), so NI had to change the internal structure of built exe's.  In 2009, exe's could be opened and listed with zip files, before that you could list files in the exe like a folder.  The path structure is still the same and still works predictably, we just no longer have the ability to list it.

There doesn't seem to be a good solution except for 1) loading the VIs into memory (somehow) and then getting the app.allVIs list 2) knowing the list of VIs at build time and hard coding it with static refs or path constants 3) putting the VIs to be traversed in a container (directory, lvlib, llb, etc) outside of the executable.

[ww.brown]

After talking with an NI compiler guy at a recent conference, the solution to finding a VI's path in an executable when only the VI's location at build-time is known, has been solved (see attached VI).

Say I have a VI: C:\myapp\mydir\my.vi with an executable built to: C:\myapp\builds\my.exe.  In this simple example, under LabVIEW 2009 and higher, the VI's file specifcation in the executable is: C:\myapp\builds\my.exe\mydir\my.vi.  In this case, the trunk directory name that is required to find the VI file specification in the executable is mydir.  Note the executable file specification is provided by an icon in LabVIEW 2009 or higher.  Combining the executable file specification with the trunk and the VI's build-time location gives you the desired result.

The problem arises when a new VI is added to the application: C:\otherapp\otherdir\other.vi.  Then the new trunk directory is the C drive: C:\myapp\builds\my.exe\myapp\mydir\my.vi.  Notice how the trunk has changed from mydir to C:\ to allow for the new VI: C:\myapp\builds\my.exe\otherapp\otherdir\other.vi.  The problem is to determine at run-time which trunk to use without knowing anything about the other VIs in the application.

My attachment demonstrates the solution.  On the first call, you discover the trunk directory by trial and error.  Once you have found the trunk, it is valid for all other VIs in the application.  A future version of LabVIEW could facilitate this algorithm by providing the trunk directory with an application property node.  Hey, maybe LabVIEW does this already and I missed it!.