plugin architecture

[DFGray]

aartjan, you can easily run a VI from within an executable.  The key is finding the path to it so you can load it.  As mentioned above, I usually use a statically linked VI whose job is to return the path - works during development and in the executable.  If your entire plug-in(s) is in the executable, this should cause no problems.  I successfully used this method for many years.  You cannot use the library namespacing method with this unless you also rename the files - an EXE has no file structure, so cannot contain two files of the same name, just like an LLB.

However, I have not tried to build an executable since LabVIEW 7.0, and I know how frustrating the 8.x build process can be.  I have used it to generated LLBs and source code distributions.

[tst]

---

@DFGray wrote:

However, I have not tried to build an executable since LabVIEW 7.0

---

If I understood your explanation about how a VI is owned by a library correctly, I believe that using libraries will not help - The main problem here is with cross linking vi.lib VIs which are shared between different plugins.

At least before LV 8, building an EXE puts the vi.lib VIs you used into the EXE. I assume this is still the same. Since in this case we build most of the code as an LLB, we need to include vi.lib VIs in the LLBs and we then get the same VI in different LLBs. Since you have vi.lib and don't build an executable, you don't run into that problem.

[aartjan]

DFGray: the method to call a VI directly inside an executable no longer works since LV8: the error states that this has something to do with library namespacing (whether the called vi is in a library or not). Real bummer, but with executable plugins, flowing data in and out becomes a completely different story.
I think I should consider building plugins as dll. At least these can be wired.

Aart-Jan

[DFGray]

tst, you would need to move the vi.lib VIs into a uniquely named library to prevent cross-linking.  This can probably be automated, but having not tried it, I don't know how far.  The basic idea is to copy all the VIs in the dependencies folder of your project to a new folder on disk, then put them in a uniquely named library before you do your build.  There are a lot of linking issues that would need to be dealt with, some of which may not be possible.  You can certainly do it manually by opening up everything, doing the move and library creation, saving and then doing your build.  However, this would be extremely time consuming, and may not work due to memory issues, for large projects.

Something to think about for a future LabVIEW feature...

[tst]

---

@DFGray wrote:
The basic idea is to copy all the VIs in the dependencies folder of your project to a new folder on disk, then put them in a uniquely named library before you do your build.

---

I believe that's essentially what the OpenG builder when you build a namespaced LLB, minus the library part. It would seem that the main advantage in using a library here is if you open VIs dynamically by name (assuming you can still use the file name when they are part of a library).

By the way, you piqued my interest now...
Can you tell us what it is you actually do at NI?

[aartjan]

Pinky, are you pondering what I'm pondering??
nice touch, tst!

I actually don't think there is an issue with vi.lib copies when using the plugins. There is more of an issue with building and debugging them.
When a plugin is calling a vi.lib VI that was included in the llb during the build, and it happens to be in memory already because the executable is using it too, I sure hope it will automatically choose the one in memory. Not positive, though.

Started using 8.5 today, and I feel it may be helpful to improve my plugin efforts. Will know more soon.

AJ

Message Edited by aartjan on 09-12-2007 04:29 PM

[DFGray]

I took a look at the 8.5 builder yesterday and discovered that there is a new feature - you can build into a new library.  This would make namespacing your dependencies (including all the vi.lib ones) fairly easy.  In your build process, specify the dependencies be put in a location which is a library.  If you make this library a different name for each plug-in, you should be good to go.

tst, in answer to your question, I am attempting to take over the world using LabVIEW!  I develop applications and infrastructure using LabVIEW.  From my posts, you should be able to figure out most, but not all, of the products I have worked on (and the ones I haven't ).

[aartjan]

You are right! I included an image that shows where you can configure this.
Tried it and works, sort of...
It will not find the VIs of the library during the build! I had to browse to each and every member of the plugin library.
The builder appears not to realize it had just nested the library into another one, thus no longer finds the VI members.

I'd say it is a cool new feature with a bug

[tst]

---

@DFGray wrote:

tst, in answer to your question, I am attempting to take over the world using LabVIEW!  I develop applications and infrastructure using LabVIEW.  From my posts, you should be able to figure out most, but not all, of the products I have worked on (and the ones I haven't ).

---

Good. It always seems to users that there aren't people within NI actually using LabVIEW for real work.

Let me guess, you wrote the HDF5 VIs and you work on working with large datasets?

Actually, it's unfortunate. I was at NIWeek, but I didn't think to seek you out. I guess you weren't visible enough around then and with so much to do I didn't think about that.

[aartjan]

The irony: Lab rats using LabVIEW!

I am currently updating my plugin player and plugins to 8.5. It has already enabled me to root out some bad linkages. I hope it will all I need to do to produce reliable plugin distributions.