Labview Call Library Node (DLL) Exception

[Travis_M.]

Good afternoon everyone,

Even if the proposed workaround fixed the problem, the issue would be unresolved – I would like to determine what is going on here!

Basically what I was pointing out earlier is that regardless of whether we use a string constant or a path control converted to a string, your DLL is taking in a cstring input and doing something with it.  The something here is very unclear to me (I do not have the means to see the source code of that right now), but the string passed to the dll is nothing more than a char array with a null character at the end.

To proceed with debugging I would really like to examine things from the DLL side of things.  The absolute first thing that needs to be determined is whether or not the string information passed to the DLL is the exact same in the case where the DLL ‘works’ and when it ‘fails’.  If the parameters passed to the DLL are the exact same in both of these cases, I give my 99.99% confidence that the code in the DLL is to blame!  If this is the case, I am really curious as to what the ‘browsing’ to the file does to change things, but we would have to investigate that further at that time.  If the data (parameters) being passed to the DLL are different then we need to determine why LabVIEW is sending different data depending on whether or not a user has reselected the file through browsing to it.

Is there any way we can do some debugging from the DLL?  Is this a DLL that you can add lines of code to and recompile?  Is it legal for you to post snippets of their code from the DLL?

[tpascaru]

Hello All,

Just to recap:
Re:

Even if the proposed workaround fixed the problem, the issue would be unresolved – I would like to determine what is going on here!

Working scenario: text file is in the macraigor directory, and i have to refresh the file path with browse.
Failing scenario #1: text file is in the macraigor directory, and i executre the DLL without refreshing the file path (dll exception error)
Failing scenario #2: I move the text file outside the macraigor directory and execute... I get an error from within the DLL (wired to my "error out").

Working scenario #2: I move the text file outside the macraigor directory, and call the DLL from a non-labview source.

Hopefully this clarifies any confusion I might have generated.

On to the next point. Travis, I agree with you 100% that the DLL is probably doing "something" to the string input, but I've verfied by attaching probes and indicators that the string is the same for both the working and failing scenarios. This is only the input string that I can probe of course. Since the DLL exception error causes the vi to stop, it never gets to the point where I can probe the output string (or, what the string looks like AFTER DLL execution). In the working cases, the string looks the same at the input and output.

This is defintely some grey area of why this is failing. Labview works with all other DLLs, so it seems like a DLL issue. However, the Macraigor DLL interfaces with all other softwares properly except for Labview, so they say it's a Labview issue.

I can ask them for source code, but judging by their past lack of responsiveness, I doubt I will be able to get it.

Regards
-Ted

[.avi file]

Greetings!

     We ran one simpler test towards troubleshooting the problem. This was to show if re-browsing to a path changes anything on the CString going to the DLL being called. We were able to create a DLL in LabWindows / CVI that takes in a File path or a String. We then passed displayed the string in CVI and passed it out to LabVIEW. The string passed out of the DLL to LabVIEW was same irrespective of whether we browsed to a specific path or had that path saved as default for that particular control.

This makes me further believe that the issue is not towards LabVIEW handling file paths. Please let us know if you hear anything from Macraigor. We would like to make sure we test it with all resources / code we have.

Hope this helps

Best regards

Avi Harjani

[Travis_M.]

Yeah, I tried to recreate this too with a C DLL.  Basically the C function just took in a C String pointer and printed a dialogue box with the contents of the ctsring.  Sure enough – no change at all in the contents of the string being passed to the DLL when I browse to the path, or when I open the VI with defaults.  I don’t see any differences in the string passed to the DLL.  Also, I notice that every time the VI is run the string is ‘reset’ to the value of the path indicator (in “browse” or “default mode”), if I try to modify the string in the DLL by changing characters in the String in the DLL, the value of the string passed to the DLL on the next run of the VI is still the same (this means that the cstring passed to the DLL is always computed in the exact same way from the path control – whether it was browsed to or loaded with default values, and whether or not the DLL has modified the DLL in a previous run – the string is always the same)!

Has anyone been able to get a simple function in a DLL to reproduce this behavior that has the source they could attach?  Could your DLL be working with Windows in some way – i.e. the browse box brought up comes from a Win SDK call, could this Windows call change anything?

Here is some of the snippets of C code I used in my DLL:

//test 1 – used with browsing to path, and loading path

//from default – the string was the same in both cases

void __stdcall StringFunc (char * in)

{          int in_length;

            MessagePopup ("",in); // CVI function to print the string to popup

}

//test 2 – used to see how changing the string in the DLL

//changed the txt.  I tried changing intermediate characters

//as well as changing the last null character to a real char

void __stdcall StringFunc (char * in)

{          int in_length;

            MessagePopup ("",in);

//in_length = strlen(in); // choose either line

//in_length = 1;

            in[in_length] = 'ñ';

            MessagePopup ("",in);

}

Until we can get some sort of small snippet of C code which can reproduce this, I really don’t know what else we can do….

[tpascaru]

Thanks for all the inputs... I have no doubt that the string is always the same when converted from the path. I was thinking of trying some more experiments using different string inputs instead of path inputs and seeing how that works. I have no inputs from Macraigor whatsoever.

I'll report back with what I find if anything.

Cheers
-Ted

[maximint]

Hi,

I had exactly the same probelm like described in the first message of this threat.

The issue was solved by entering a path variable (Win XP --> Sytem-> Advanced->Environment Variables)

with the path where the DLL is located.

Best regards.

[rolfk]

---

maximint wrote:

Hi,

I had exactly the same probelm like described in the first message of this threat.

The issue was solved by entering a path variable (Win XP --> Sytem-> Advanced->Environment Variables)

with the path where the DLL is located.

Best regards.

---

The real issue here is that the DLL does something internally that relies on the current directory to be the same as where the DLL itself is. That is a very bad assumption in an environment like Windows. The file dialog used by LabVIEW is the standard Windows File Dialog and that has the stupid notion to set the current direcotry to the directory displayed when the OK button is pressed. You could also have executed the SetCurrentDirectory() Win32 API just before calling the DLL and probably got the same, although that is not entirely safe since your LabVIEW program might display the File Dialog in some other part of your program in between setting the current directory and executing the DLL function.

The real solution would be to fix the DLL to rely not on something stupid as the current directory. The current directory is not something a GUI application should ever rely on and certainly not a DLL, since it's programmer can not envision all the use cases for the DLL.

Rolf Kalbermatter

Message Edited by rolfk on 02-19-2009 11:42 AM

[maximint]

Hello Rolfk,

thanks for your reply to this issue. I'm afraid that I don't understand in detail how from your point of

view the location of the DLL should be programmed correctly.

Could you please explain again in other words or  could you tip me on a simple example.

Many, Thanks.

---

rolfk wrote:

---

maximint wrote:

Hi,

I had exactly the same probelm like described in the first message of this threat.

The issue was solved by entering a path variable (Win XP --> Sytem-> Advanced->Environment Variables)

with the path where the DLL is located.

Best regards.

---

The real issue here is that the DLL does something internally that relies on the current directory to be the same as where the DLL itself is. That is a very bad assumption in an environment like Windows. The file dialog used by LabVIEW is the standard Windows File Dialog and that has the stupid notion to set the current direcotry to the directory displayed when the OK button is pressed. You could also have executed the SetCurrentDirectory() Win32 API just before calling the DLL and probably got the same, although that is not entirely safe since your LabVIEW program might display the File Dialog in some other part of your program in between setting the current directory and executing the DLL function.

The real solution would be to fix the DLL to rely not on something stupid as the current directory. The current directory is not something a GUI application should ever rely on and certainly not a DLL, since it's programmer can not envision all the use cases for the DLL.

Rolf Kalbermatter

Message Edited by rolfk on 02-19-2009 11:42 AM

---

[rolfk]

---

maximint wrote:

Hello Rolfk,

thanks for your reply to this issue. I'm afraid that I don't understand in detail how from your point of

view the location of the DLL should be programmed correctly.

Could you please explain again in other words or  could you tip me on a simple example.

---

Windows (and the underlaying C runtime library) knows something called current directory. This is maintained on a per process base and there exist some Windows APIs SetCurrentDirectory() and GetCurrentDirectory() to change and query that path. The C runtime also knows some functions (something like cd() and pwd() or similar).

Some APIs such as the native Windows file Dialog also influence this since it calls SetCurrentDirectory() with the actually selected directory when you dismis it with the OK button.

Now the problem is that some file APIs (especially the C runtime ones) will simply prepend the current directory if they get passed a relative (non root, eg. not starting with a drive letter) path. This is ok in a command line tool since the current directory of a process gets initialized to the directory where it got started from, usually the directory it is located in. For a GUI app or a DLL, use of such APIs with relative names is simply a bug. You can never rely on the current directory to be anything specific in such code.

Instead a DLL should use explicit APIs such as GetModulePath() to get the path to its directory and then append whatever file name it wants to acces, if it wants to access a file that resides along the DLL in the same directory.

Rolf Kalbermatter

[surfnska]

I'm having this same problem with a Macraigor dll as well.  I'm curious if anyone has tried calling their dll's with TestStand?  We don't currently use TestStand, but I would like to move to it, and if Macraigor dll's play nice with it then I might be able to persuade my boss into purchasing.