How to call a dll that internally runs a different dll

[RicardoHdez]

I have a dummy dll that generates a random number (0-100) integer of 16 bits *Random1

I have another dummy dll that calls (with external path) the first dll and generates a second random number  *Random2

I want to call the second dummy dll with an string input that is the path of the first dll and the output defined as Random1 and Random2 (both integer of 16 bits)

But Labview got freeze and I cannot continue, the parameters are automatically upload, so I believe the calling way is not an issue.

Do anyone know how to call a dll that runs a dll?

*PS: I have LabVIEW 2014

[wiebe@CARYA]

Calling a dll that calls a dll should happen automatically. Nothing special should be needed.

The dlls need to be able to find each other of course. If not, it won't load. Or produce an error when the function is called on a dynamically loaded dll.

If LabVIEW hangs when you call a dll function, there something else is wrong...

[wiebe@CARYA]

To be honest, I never tried this. I don't see why it wouldn't work.

Anyway, I'd first try to call the dll statically. So not by specifying the path. Just to see if that's the problem.

I don't think we have all the information. The calling protocols are probably from the configuration? OIr from the build? Or both? Hard to tell from screenshots. But if they don't match, it's a problem.

I'd also wire some inputs on those pointers. Not required, but I did notice some obscure behavior when parameters didn't have an input (like old values being returned repeatedly).

Post a zip of the project. Someone will look at it.

[rolfk · Accepted solution]

Set the Call Library Node to be reenrtant (light yellow). If you have them configured to run in the UI thread they naturally have to lockout each other. Even Windows itself does not like LoadLibrary() (or FreeLibrary()) calls inside the DLL initializtion routine as that will easily create race conditions or complete process lockups.

Basically you start the first DLL in the UI thread but LabVIEW needs to do all kind of stuff in the UI thread and loading a LabVIEW DLL into LabVIEW is not as straightforward as it may appear since you have the possibility that the DLL was compiled with a different LabVIEW version than the one that is calling it, so it has to potentially be instantiated out of process in the according version of the LabVIEW runtime.

[RicardoHdez]

---

@rolfk  ha escrito:

Set the Call Library Node to be reenrtant (light yellow). If you have them configured to run in the UI thread they naturally have to lockout each other. Even Windows itself does not like LoadLibrary() (or FreeLibrary()) calls inside the DLL initializtion routine as that will easily create race conditions or complete process lockups.

Basically you start the first DLL in the UI thread but LabVIEW needs to do all kind of stuff in the UI thread and loading a LabVIEW DLL into LabVIEW is not as straightforward as it may appear since you have the possibility that the DLL was compiled with a different LabVIEW version than the one that is calling it, so it has to potentially be instantiated out of process in the according version of the LabVIEW runtime.

---

Thanks it works!