Jarrod S.
2006-05-11 23:40:08 UTC
Hi Mike, I've been working on a method that I hope should work for this application. I haven't been able to test it on a computer that doesn't have the LabVIEW development system installed, but I have come across the same type of missing VIs errors that you experienced in some of my earlier tries, so I hope this will resolve them.What I would suggest to you is to build your dataplugin VIs into executable packages, even if you don't intend to ever double click and launch those executables. The idea is that by building them into that type of package, LabVIEW will package them with all the DLLs and subVIs they require to run. Then you can launch the VIs by opening references to them at directories like myapp.exe\myVI.vi or whatever. You can also use the List Directory advanced file function to search for VIs in the myapp.exe directory.The only problem here is that you'll not only find the dataplugin VIs you want with that method, but also all their subVIs. It might be difficult to separate the few VIs you do want from the dozens of subVIs you don't want to open references to and launch. So I have a solution for that too.My first idea was to build the executable, but include the dataplugin VIs of interest in the destination directory instead of the exe package itself. This sort of works. Although this makes it easy to find the VIs of interest, when you open up a reference to the VIs and open their front panels, the run-time engine will have to search for the subVIs which are contained in the exe. Since they're all in the same folder, they will be found, but you'll see that searching dialog which pretty much strikes this as a possibility.Instead, the better option is to include all your dataplugin VIs in one or more Project Libraries. Then include the whole Project Library under Startup Vis in your build spec. When you build the package, LabVIEW will include all the necessary subVIs and DLLs, as well as the .lvlib file itself that contains the names and paths of the relevant dataplugin subVIs. Your app that calls the dataplugins could then search the exe file for *lvlib files (or better yet, give them some sort of identifiable name to distinguish them, like DataPlugin*.lvlib), open references to the Project Libraries, and then derive the VI references from there.I know this might be a lot to take in, but the end result is a rather robust solution to the problem, where all the linking requirements are taken care of. It also provides a rather easy way to package your dataplugins. Just throw them all in a Project Library called DataPlugin*.lvlib or whatever, then build the whole thing with the library set as the Startup VI.I'll attach an example below. Again, I haven't tested this on a non-LV machine, but I can only imagine it would work, since at that point the exe file with the dataplugins should be completely self-sufficient. Let me know how this works out, or if you have any advice to improve on this!Just unzip the dataplugins zip file. That contains the project with the library with the plugins and the correct build spec. Build that exe, then take a look at Caller.vi, which searches through the exe for Data*.lvlib files and opens references to all its VIs. Hope this helps!
DataPlugins Project.zip:
http://forums.ni.com/attachments/ni/170/184471/1/DataPlugins Project.zip
Caller.vi:
http://forums.ni.com/attachments/ni/170/184471/2/Caller.vi
DataPlugins Project.zip:
http://forums.ni.com/attachments/ni/170/184471/1/DataPlugins Project.zip
Caller.vi:
http://forums.ni.com/attachments/ni/170/184471/2/Caller.vi
