Using filename as input to DLLs

[T-Hawk]

Background:

I have written a DLL using C++ and I am accessing this DLL from LabVIEW using the Call Library Function.  One specific function I have in my DLL opens a file (which is passed in as a parameter) and operates on the data.  I need to specify the filename using LabVIEW, so I have a "path" control on my front panel.  After converting this path to a string, I pass it into my DLL as a Cstr Pointer. 

Problem:

It appears that I am perfectly capable of opening files that are contained in the same directory as the LabVIEW vi.  If I try to access an exact replica of the same file in a different directory, LabVIEW chokes and says there's an error in the DLL function that I am using.  Even more strange, I had a duplicate folder that contained the same dll, and when I would copy a file into the duplicate folder and access it through the ORIGINAL vi, LabVIEW wouldn't crash.  Not sure if that's helpful or not.

Things I've tried:

I noticed that the path control in LabVIEW has backslashes instead of forward slashes.  I figured this might be a problem since the "\" character in c++ is to denote special characters.  So I converted all "\" to forward slashes.  Still had the same problem.

Any advice would help.  Thanks a lot!

T

[rolfk]

---

@T-Hawk wrote:

Background:

I have written a DLL using C++ and I am accessing this DLL from LabVIEW using the Call Library Function.  One specific function I have in my DLL opens a file (which is passed in as a parameter) and operates on the data.  I need to specify the filename using LabVIEW, so I have a "path" control on my front panel.  After converting this path to a string, I pass it into my DLL as a Cstr Pointer. 

Problem:

It appears that I am perfectly capable of opening files that are contained in the same directory as the LabVIEW vi.  If I try to access an exact replica of the same file in a different directory, LabVIEW chokes and says there's an error in the DLL function that I am using.  Even more strange, I had a duplicate folder that contained the same dll, and when I would copy a file into the duplicate folder and access it through the ORIGINAL vi, LabVIEW wouldn't crash.  Not sure if that's helpful or not.

Things I've tried:

I noticed that the path control in LabVIEW has backslashes instead of forward slashes.  I figured this might be a problem since the "\" character in c++ is to denote special characters.  So I converted all "\" to forward slashes.  Still had the same problem.

Any advice would help.  Thanks a lot!

Are you working on Unix!!!! Windows uses always backslashes for path separators. You do not need to escape the backslashes. That is only necessary for the C compiler in order to know that it should use the actual \ ASCI code instead of trying to interpret the following character(s) as backslash codes. Once the C compiler has processed the C source file a single backslash is placed into memory just as what LabVIEW passes to your DLL.

Are you using absolute file paths? Relative file paths always have the difficulty to where they reference. Under Windows and the ANSI C library there is a concept of a current directory that is maintained by Windows on a per process base. It is used by most ANSI C functions as base when given a relative path as input. But under Windows this makes not much sense since various Windows APIs will reset that current directory path such as File dialogs and similar.

I guess once you have made sure that above comments are correct the next step would be to debug into your C source code with your source level debugger of your choice. 99.9999999999999% chance that you do something wrong in your C code, which is also my own experience too.

Rolf Kalbermatter

[T-Hawk]

I am in Windows, not Unix. 

I am using absolute paths.  In LabVIEW, the path control automatically selects the absolute path.  If you work with LabVIEW, you could verify this for me and make sure that's correct.

Actually, I have debugged my C code to no end.  If I run my C DLL using a C console application, I can pass any file path I want to and it always works!  That's what's so frustrating.  That tells me that there's something causing my VI and my DLL to not play nice.

Can you think of any reason why it appeared to work when I specified a filename contained in a distant folder that contained a copy of the dll?

Thanks for your help!

[TCPlomp]

T-Hawk,

have you tried entering an easy path with just a string indicator (c:\test.txt)?
I think the calling convention will (most) probably be the source of the error!

Ton

[T-Hawk]

I only have LV 8.0.  I would have to create a new dll to post along with my vi, as I cannot be posting the one I'm using currently...

Great suggestions though.  I had tried using the string constants before, but I did it a more systematic way this time.  I hope I can explain it as systematically as I ran it.  Here's what happened.  Very strange.

1) Used string constant c:\test.txt in the call to the DLL from LabVIEW.  Program worked perfectly.  I am running my software off a server here, so I also made a test file in a very simple folder on the server, lets call it \\ myserver\folder\test.txt.  Program worked great.  I also switched back and forth between these two string constants every other run...and that seemed to be fine.

Here's where it gets weird.

2) I then accessed c:\test.txt using the path control in LV and the program worked GREAT.  After the completion of the vi, I changed the path name to \\ myserver\folder\test.txt and LV choked.  So I closed everything out, and tried the same thing...using \\ myserver\folder\test.txt FIRST, and c:\test.txt SECOND.  Interestingly enough, \\ myserver\folder\test.txt worked just fine, and c:\test.txt was the one that caused a crash.  Every single file I have tried...no matter where it is located, APPEARS to work just fine onthe FIRST run, and then once the path name is changed, all goes to hell.

3) Other things I tried:  I ran the program using c:\test.txt multiple times, and everything was great.  I also switched back and forth between the working text file from the path, and the string constants, and the string constants ALWAYS worked...even if the very same file name from the path control caused a crash previously.

Other note of interest: you know how if you create a new file using ofstream (i.e. myfile.txt) in C and fill it with stuff, the program will create that file in the directory that it is running in...correct?  Well, if I create a new file inside the function that I'm calling with LabVIEW, it does NOT always show up in the home directory...it actually creates the file in the same directory as the path control.

Is there a possibility that the path control somehow changes the directory in which the program is running?  I know that's crazy...so I'm sure you're laughing at the stupidity of that suggestion.  I'm just so out of ideas for this crazy problem!  If I'm not presenting this to you very well, please feel free to throw in the towel. 

T

[TCPlomp]

---

@T-Hawk wrote:

 Well, if I create a new file inside the function that I'm calling with LabVIEW, it does NOT always show up in the home directory...it actually creates the file in the same directory as the path control.

Is there a possibility that the path control somehow changes the directory in which the program is running?  I know that's crazy...so I'm sure you're laughing at the stupidity of that suggestion.  I'm just so out of ideas for this crazy problem!  If I'm not presenting this to you very well, please feel free to throw in the towel. 

T

---

Hi T-Hawk,

I think I know what happens, if you browse to a folder and select a file there, LV set that as the home directory, BUT I COULDN'T VERIFY THIS

Have you set your dll reentrant (thread safe?)

Ton

[T-Hawk]

Okay, so I'm not crazy. 

Here's the thing.  I'm TOTALLY new at DLLs and LabVIEW.  The way I created my dll was I let Microsoft Visual Studio do all the work.  When you say "did I set my reentrant?" I would like to say yes, but I can't be sure.  Here's what I think is what you are asking if I did:

//Excerpt from FileIO.h

//Here are my export symbols

#ifdef

FILEIO_EXPORTS

#define

FILEIO_API __declspec(dllexport)

#else

#define

FILEIO_API __declspec(dllimport)

#endif

//Excerpt from FileIO.cpp

//Here is my function definition

#include

"stdafx.h"          //don't think this header does much.  MSV added it for me

#include "FileIO.h"

BOOL APIENTRY DllMain( HANDLE hModule,

DWORD ul_reason_for_call,

LPVOID lpReserved

)

{

switch (ul_reason_for_call)

{

case DLL_PROCESS_ATTACH:

case DLL_THREAD_ATTACH:

case DLL_THREAD_DETACH:

case DLL_PROCESS_DETACH:

break;

}

return TRUE;

}

//Example of my DLL function

FILEIO_API

void OpenFile(char *filename)

{ //opens file, makes use of its contents

}

Sorry about the weird formatting from the copy/paste.  That's basically ALL I'm doing with the DLL.  Does this look like I'm missing something to you?

[rolfk]

---

@TonP wrote:

Hi T-Hawk,

I think I know what happens, if you browse to a folder and select a file there, LV set that as the home directory, BUT I COULDN'T VERIFY THIS

Have you set your dll reentrant (thread safe?)

Ton

---

Actually setting of the current directory is a feature of the Windows file dialog as mentioned in my earlier answer. Nothing LabVIEW would need to do for that in contrary, LabVIEW would need to do something specific in order to not have the current directory changed by the file dialog. But since LabVIEW itself does not use the current directory maintained by the OS for anything it simply doesn't care.

Rolf Kalbermatter

[T-Hawk]

I'm sorry, I don't know if I understand what that means.  If LabVIEW "doesn't care" what directory is considered the "home" directory, why am I having the problem that I am having and what other steps should I be taking to solve this?  I'm convinced that the DLL is dependent in some way to where the home directory is set, so I'm wondering if this is the problem.

If nothing else...you said that LabVIEW had to do something special to NOT change the home directory.  Any idea about what needs to be done, or how I can figure out how to make that change?

Thanks!

T

[rolfk]

---

@T-Hawk wrote:

I'm sorry, I don't know if I understand what that means.  If LabVIEW "doesn't care" what directory is considered the "home" directory, why am I having the problem that I am having and what other steps should I be taking to solve this?  I'm convinced that the DLL is dependent in some way to where the home directory is set, so I'm wondering if this is the problem.

If nothing else...you said that LabVIEW had to do something special to NOT change the home directory.  Any idea about what needs to be done, or how I can figure out how to make that change?

Thanks!

T

---

You can't change LabVIEW itself since you do not have the source code. Also the term home directory is a bit misleading here. What probably is the problem here has more to do with the so called current directory, an artefact from the standard C library implementation and also somehow present in Windows, though applications depending on that will very likely run into all kind of problems. Several Windows APIs will change that current directory including the Windows file dialog when you select a file and close the dialog with OK. But this problem only can occur if you use low level system functions or standard C library functions with relative file names. No function receiving a valid absolute path should rely in any way on the current directory.

If you need to have a specific current directory somewhere you can call the Win32 API SetCurrentDirectory() and hope that no other part of code you call might silently reset that directory to something else. This will then also for instance be the start path of the file dialog, if no valid start path has been passed to it. Note that for most LabVIEW file functions that operate on directories however an empty path is not considered invalid but rather the placeholder for the desktop. To specify an invalid path you need to use the canonical invalid path constant "Not a Path".

Rolf Kalbermatter 

Message Edited by rolfk on 12-14-2006 10:59 PM