01-11-2018 03:02 AM
@NSpada wrote:
The library (VTXDLL-NT.dll) has many dependencies, all of which I keep in the same folder as my VIs.
This is most likely the problem. The directory where your main DLL is is absolutely not something Windows will use when searching for dependencies. Neither is the directory where your VIs are located (Windows has absolutely no idea about what VIs are nor why the directory they are located in should be treated in any special way.
Instead Windows will search in these locations:
1) Already loaded in memory? use this DLL
2) In the current process application directory ( Where LabVIEW.exe is located or for a build application your MyBuildApp.exe)
3) If SafeDllSearchMode is disbled the current directory (this is totally insecure as the current directory can change at any time, including when you open a file dialog in LabVIEW and acknowledge a file selection)
4) Windows\System32 (Windows\SysWOW64 for 32 bit applications on a 64 bit system) directory
5) Windows directory
6) The directories listed in the PATH environment variable
Each of these locations has positive and negative issues. Use of the Windows and System directory should be avoided in most situations as those directories are already cluttered enough. My quick and dirty test situation is to put them in the LabVIEW directory, the more professional solution is to use the PATH environment variable although you can run into issues if that variable contents gets longer than about 1600 characters.
For build applications the best solution is to put all the DLLs into the executable folder.
01-12-2018 12:10 AM
Thank you very much!
I first copied all the necessary files into the same folder as LabVIEW.exe, but that did not solve the issue. I then used the Import Shared Library wizard and copied all the necessary files into the same folder as the newly created VIs and that seems to have worked. The function calls are behaving as I would expect so far.
Thanks again for your help.
01-12-2018 02:08 AM
Sounds wrong. That directory has absolutely no meaning for Windows DLL dependency resolution and it shouldn't be able to find the secondary dependencies there unless that directory happens to be also the current directory which could be as you had to select the DLL in the Import Library Wizard with a file dialog. The native Windows dialog changes the current directory to the directory in which you selected a file and confirmed the dialog with OK. But then this will fail again the next time you restart LabVIEW as the current directory will be set to something else again.
01-22-2018 04:59 PM
Sorry for the delay. You're right, as soon as I restarted LabVIEW, I received the 1001 error from the detector again (Error loading XIA systems). Since this is not a build application, I used your recommendation to put the files in the windows/System directory. The detector responds now even after restarting LabVIEW.