File path that DLL uses by default

[expfox24]

I have successfully implemented a DLL that is called within LabVIEW, however when I try to open a file the file is not found.  It is looking for a specific file and cannot find it. 

What is the default location where the DLL searches and can I change it?  I assumed it would be in the same location as the LabVIEW project.

[cbutcher]

At first I was going to post a link to the search path LabVIEW uses for DLLs, but it sounds like you've written a C or C++ DLL and that is the bit that can't find a file?

In that case, you'll need to check how the function you're calling in the DLL expects paths to be constructed. It might require an absolute path, or it might be relative to the DLL, etc.

Can you share the code that's searching for the file?

[rolfk]

You need to give more information how your DLL tries to access that file. The DLL definitely knows nothing about the LabVIEW project (even if it was a LabVIEW DLL created from LabVIEW VIs it is not running with the project context in any way and if it is a DLL created for instance in C/C++ or C# it won't have any knowledge of LabVIEW files at all).

Unless you use absolute file paths you need to know about the path resolutions of the APIs your are using. Most Windows API functions for instance standardize relative paths by prepending the so called Current Working Directory to it. This is a process specific global that Windows maintains and which on process creation is initialized to the directory in which the executable is located that starts the process. For the LabVIEW Development environment this is the directory in which LabVIEW.exe is located, for a build application it is where your <myApp>.exe is located.

BUT, the current working directory can be modified by explicitely calling the SetCurrentDirectory() WinAPI. It also gets automatically updated by Windows whenever the FileDialog is acknowledged by the user with the directory the selected file is located in.

Because of this the use of relative paths when calling Windows APIs from a GUI application is a disaster waiting to happen. You should always try to refrain from doing that!

[expfox24]

Thanks for responding, the command in the DLL is a simple fopen command:

const char FILE_STM32_BINARY[] = {"Test.bin"};

 pFile = fopen(FILE_STM32_BINARY,"rb"); // Open STM32 code file in binary mode.

[rolfk]

Thee relative path used in there is your problem. Windows file IO will resolve such paths to the process global Current Working Directory. On process start this is normally initialized to the directory in which the actual executable is located that started the process, unless the invoker chose special settings.

However this path can be at any time updated in a program by calling the SetCurrentDirectory() Windows API. Any code you call in your program such as DLLs, ActiveX components, and .Net Assemblies may decide to change the current directory for whatever obscure reasons, so assuming that it has a certain value is sooner or later biting you in what the first three letters of assume mean. This is especially true as Windows itself always changes that directory to the actual directory from which you chose a file in the file selection dialog. And LabVIEW uses that file selection dialog too, so as soon as you chose some VI or other file inside LabVIEW the current directory has been changed automagically too.

A nasty (IMHO) workaround is to always call SetCurrentDirectory() to whatever you want your DLL function to refer to before you call file functions with relative paths in your DLL, either in the DLL itself or in LabVIEW just before invoking your DLL call. 

[expfox24]

I'll try this.  I assumed it was more to do with the default paths in the .ini file.

Any way of displaying what the current path is?

[rolfk]

---

@expfox24 wrote:

Any way of displaying what the current path is?

---

Sure! Call GetCurrentDirectory() Win API. Just watch out you need to really call the GetCurrentDirectoryA() function and of course create a buffer before calling that function in which the GetCurrentDirectoryA() function can write the path into.

Just for fun I created that function for you and attached it.

[expfox24 · Accepted solution]

I've just implemented writing the current directory and it worked.  The directory being pointed to was the C:\Windows\System32 directory which I'm assuming it didn't have access to.

Many thanks.

[rolfk]

That's a terrible hack and pretty unlogical!

Instead your DLL should use a well known path location instead of relaying on an unreliable current directory, Other threads in a program could change that path at anytime to something else, including between your call to set the current directory and calling your DLL.

If you want to access a file relative to your DLL you should program it in that way by querying the DLLs path and appending the location to that path and then pass that absolute path to the file function. Relative paths in a multithreaded application (which LabVIEW inherently is) to access files on disk is a terrible hack waiting to break sooner or later.

All LabVIEW functions accessing a file on disk will refuse relative paths explicitly with an argument error (1).

[expfox24]

Ok I've changed to look for a fixed path that is created as part of the installation: 

C:\Program Files\Common Files\...

Thanks for the advice.