08-30-2021 07:36 AM
Hi Rolf,
thanks for the reply. Yes, they have their own collection of shared libraries. However, i have listed this directory in the system variables under "Path" since my MATLAB code (before creating a dll from it) has to now also where these dlls are stored. If I understand correctly LABVIEW should be able to find them if they are listed there. My end goal would be to use my MATLAB function on my real time Target. I think there I will encouter this problem. So for future reference, how can I tell my realtime target where these dlls are?
Back to my current problem, could there be any other issues result in this error I am expierencing?
Cheers,
Jeremy
08-30-2021 07:58 AM
LabVIEW doesn't deal with loading secondary DLL dependencies at all! It simply passes the path to the direct dependency to the Windows LoadLibrary() API and the rest is standard Windows behaviour. LabVIEW can't and shouldn't even try to bother about trying to detect secondary dependencies. It's an endless and for LabVIEW totally unsolvable problem!
09-06-2021 07:58 AM
I could resolve the problem. It seems the issue wasn't the secondary dependencies. The problem originated from the Input of my function. One of the Input variables was a path to a file. This file input needed the absolut path instead of the relative path to the vi or location of the dll.