Application with Plugins

[J.A.C]

Hi,

I am having an application where i need to use VIs as plugins. However when i built exe out of main VI. I need to add all dynamic VIs as part of application built process. Due to this the plug-in nature of VI's is lost. By that i mean, if i add more VIs to the plugin directory then my main exe fails to recognize it as they were not included (in dynamic VI list) during the built process. I think i am making some mistake. Can someone out there help me ?.

[RayFarmer]

Hi,

You dont have to have the Dynamic VI includes as part of the build. This is just a means of deploying everything assoicated with an application.

Can can deploy them seperately on your target system.

What you will need is a mechanism of obtaining the full path to the VI's for the Open VI function.
Whether that is including the dynamic VI's in the search path, supplying them in a file which your application can read or using the registry.

Hope this helps
Regards
Ray Farmer

[J.A.C]

Thanks for reply.
But if i dont include my dynamic VI's build application then i get "VI not executable" error when i run my application. Although the application runs well when only the source code is run (without exe, loader).

Secondly since my directory for plugin VIs is fixed say, c:\plugins, and i have hardcoded the path to this directory in dynamically called VI, why does it still give me problem ?.

Just to make clear, the picture is like Main application a.exe dynamically calling b.vi (using invoke method). B.vi in turn reading plugin directory, using open VI reference node and hardcoded file paths are passed to open VI reference.

[DFGray]

If you are using the Application Builder, you will need to manually add all dynamic VIs to the build list. How you access them in the built application usually boils down to a personal preference. Avoid hard-coded paths unless you can guarantee where your application will be installed (not a good assumption). My personal preference is to create a VI whose only purpose is to return the directory in which it lives. Place this VI in the directory with all your dynamic VIs. When you need the location of a dynamic VI, call the directory VI statically to get the proper directory, then use the build path function with the name of your VI to get the full path. This method allows you to use a nice, hierarchical directory structure for development, but ship in a single executable.

[J.A.C]

Thanks Gray,
But the problem is to have plugins, when you say you have to add all dynamic VIs while building application, the plugin nature is lost. That is in future if you add more plugins then you will need to recompile the entire application. This is not what is required. What i required is to support additional VIs (plugins) without recompiling my main application.

[Dennis_Knutson]

You do not have to include your plug-ins when building the application but the plug-in VIs have to have all of it's subVIs included somewhere. If VI "A" calls VI "B" and VI "B" calls VI "C", VI "C" must either be included in the build or included in an llb that VI "B" can find. Try creating an application distribution of your plug-in (VI "B" and see if the error goes away.

[J.A.C]

Thanks Dennis,

I did exactly the same thing, as you said, i created application out of my VI B(B.exe).

I was expecting that B.exe will correctly read the plugin directory (because b.vi reads the plugins correctly), but it did not !.

This means that something is going wrong when i create application (b.exe) out of b.vi. I doubt it on paths !. I used simple error handler VI to get the error. I received something like "VI is not executable".

Please Help.
Thanks.

[DFGray]

A "VI is not executable" error typically means that your plug-in is "dirty." When it loaded up, all of its dependencies were not in exactly the same path relative to the main VI as they were when you compiled it. The run-time engine can't find something. You won't see this in the development environment, because the development environment will find the dependencies and automatically recompile for you - usually too fast to notice.

When you create your plug-in, you don't need the app builder, just save with options and make sure all dependencies are saved, including vi.lib VIs. They won't necessarily be around for the application.

Be aware of namespace issues. If you save the same VI twice in different plug-ins, whatever is in memory first will be used. Most developers rename all their VIs with some sort of prefix when they create the development distribution to avoid this kind of problem. This includes vi.lib VIs.

[RayFarmer]

Hi,

I have attached an example, its actually an example found in the labview examples folder "examples\viserver", but slightly modified and turned into an exe file. The dynamic VI's are not included in the build.

I have saved out, using the Save with Options, one of the plugin VI 'Create Data Set.VI' plus sub-VI which are usually found in the vi.lib\analysis folder.

This backs up what I initial said plus Dennis and DFGray's comments.

Its a LabVIEW 7.0 example

Hope this helps
Regards
Ray Farmer

[J.A.C]

Thanks all for your inputs !.

I got the problem solved. It was my mistake. I had wired type specifier VI refnum to open VI reference node and during application built process i used to select disconnect all refnums....

Thanks once again.