Dynamically Loading VI using DLL

[Astro23]

Hi all,

In Labview, I have made a GUI and a library for interfacing to a device. I have compiled this to an .exe and it all work well.

I haved compiled these exposed VIs into a DLL using LV2012 and written a small C++ program that is linked to my DLL. The problem I am having is that when I run my "begin" function (it calls some dynamically loaded VIs), I get Error 7 Path not found. Now, I imagine that this is something to do with either me not including the dynamic VIs when I compile the DLL (which I am sure I have done) or, the paths somehow being changed. When I load my VI, I use a relative path constant e.g. "UserCommands\Device1\Device1CommandFactory.vi" that gets converted to an absolute path.

What do I need to do in order to get the DLL to load the VI properly?

Thanks in advance

[mikeporter]

So are you trying to open a LV front panel from a DLL call? I'm not sure that's possible.

One thing you can do to troubleshoot the Error 7 is modify your code so the name (and path!) of the file you are trying to open is included in the error message.

Mike...

[nathand]

How are you doing the conversion to the absolute path?

Do you need to load the GUI VIs dynamically, if you're compiling them into the DLL? Consider using a static VI reference instead; that way you're not relying on a path.

[Astro23]

I'm not trying to load a front panel VI dynamically. I load a "server" vi that interfaces with the device. I also dynamically load my device class. I do this because, the DLL should be able to interface with 2 different devices.

I've added the error source as an output of my begin vi and I can see that the error occurs when trying to load my device class. It's in german sorry

Get LV Class Default Value.vi<APPEND>

<b>Vollstõndige Aufrufkette:</b>
     Get LV Class Default Value.vi
     myDevice_Interface.lvlib:LoadDeviceFromAbsolutePath.vi
     myDevice_Interface.lvlib:LoadDevice.vi
     myDevice_Interface.lvlib:begin.vi
     myDevice_Interface.lvlib:begin.vi.ProxyCaller

<b>Klasse wurde versucht, hier zu laden:</b>
C:\Users\myname\Desktop\myDevice_Interface_DLL_Example\myDeviceInterface.dll\myDevice Interface\Devices\myDevice1\myDevice1.lvclass

I have included the class in the source data tab when I compile the DLL. I do specify the path to find the class as Devices\myDevice1\myDevice1.lvclass. Where should it be looking?

[Astro23]

Here is my relative path to absolute path vi

[mikeporter]

It coulld be a matter of how you are including your class. For example:

Here I have added just the class, but you can see that while the class was added to "Always Include", nothing in the class was added.

Mike...

BTW:  LVLIBs do the same thing -- and don't ask me what kind of sense this makes...

[Astro23]

So instead of using the Get LV Class Default Value vi to load mydevice  class, I tried putting the class in directly. I got no errors when I compiled the DLL or exe.

However, I tried compiling an exe and running it, using the build configuration that worked before changing the way I load the class. When I run it, I get lots of errors about not being able to load a bunch of classes and also error 2208. I tried including the classes it couldn't find (and all their vis) but I get the same error.

I've done a bit of searching and lots of people have had this error but I haven't found a solution yet.

Does anyone know how to fix it?

[mikeporter]

Dynamic loading of classes is not a problem. What I tried to show you is that including the ,lvclass includes it, but none of the VIs that are part of it. When you build your application, what does the Always Include box contain?

Mike...

[Astro23]

Hi Mike,

I have all the classes and VIs  that are dynamically loaded in my always include box. I read the Labview guide on building a DLL and I missed the statement here that says :

Note You cannot include a polymorphic VI or a LabVIEW class in the Exported VIs or Always Included listboxes. Use an instance of the polymorphic VI instead.

So I tried removing the classes and just including their VIs but, no luck.