Strange "Call Library function" behaviour

[Golziante]

I'm facing a very strange problem during last week. I need to call some functions using Call library function node.
I have done many times in the past and I'm quite sure to call the function in the right way but I need help.

Synthetically I have to call in order the following functions:

DVRInitLibrary
DVRGetLibraryVersion
DVROpenConnection2
DVRConnectSite
...
DVRDisconnectSite
DVRCloseConnection

The first three functions works fine (I have the same result using it under Visual Studio!!). The function that I'm not able to call correctly is the following:

DVRRESULT WINAPI DVRConnectSite(
DVRHANDLE Handle,
LPCSTR SiteIP,
INT SitePort,
LPCSTR UserID,
LPCSTR Password,
INT AReadTimeOut
)

The function return a generic error code that doesn't give any useful information. Attached there is an image showing the way I'm calling the function. I did a lot of trials but I'm not able to understand the problem (under Visual Studio on the same machine It works!!). Same result on LabVIEW 7.1.1 or 8.6.1 or 2009 under Windows XP.

Regards
Golzio

Message Edited by Golziante on 05-17-2010 03:42 AM

[Golziante]

 Together with the SDK that I'm trying to use there is also a .NET dll which is nothing but the same dll packaged in a .NET form.
I will be very curios to be able to test also the .NET dll under LabVIEW but when I explore the dll with the constructor node LabVIEW tell me that there is not public constructors. Using Visual Studio 2005 I also notice that the function that I want to use are declared as public static class and for this reason I don't understand why this function are not visible from labVIEW constructor node.

Thanks in advance
Golzio

[TCPlomp]

if it's a static class, I think you should drop a .net constan and select the appropriate class.

Ton

[smercurio_fc]

Actually, for a static class you would call the methods directly, selecting the class on the Invoke node. I.e., plop down an Invoke node, right-click on it, and go the the "Select Class -> .NET -> Browse..." menu item. Then navigate to your private assembly, select it, and then select the appropriate class in the assembly. The methods will then be available. You do not instantiate a static class. 

As for the DLL call, you don't show your LabVIEW code, but be aware that a CStr is not the same as an LPCSTR. The latter is a pointer to a constant string. Thus, the DLL is expecting a pointer to a memory location that contains a string that will not change.

[Golziante]

First of all thank you for your answers.

Taking into account your advice yesterday I was able to correctly connect to my DVR using the .NET solution (attached youcan find the block diagram).

---

As for the DLL call, you don't show your LabVIEW code, but be aware that a CStr is not the same as an LPCSTR. The latter is a pointer to a constant string. Thus, the DLL is expecting a pointer to a memory location that contains a string that will not change.

---

I got your point, but now I don't know how to pass an LPCSTR to this function. I also try to search here but I wasn't able to find some help.   

Regards

Bye

[Golziante]

 Attached there is a small example showing how usually I call function containing LPCSTR.

Is It the correct way in your opinion???

Regards 

Golzio

[Golziante]

The .NET LabVIEW code works but I'm not able to develop all the things I need.

The Call Library Function approach doesn't work. For this reason I also develop another simple DLL

that made all the call I need to the original DLL (in this way I completely avoid problem due to passing argument to the function !!!).

If I use this new DLL that simply wrap the old DLL the function return the generic error BUT PLEASE NOTE THAT IF I COMPILE EXACTLY this new DLL as executable It works. For sure there is something that I didn't understand!!

If someone has some ideas I can attach code and documentation.

Thanks

Golzio

[rolfk]

---

smercurio_fc wrote: 

As for the DLL call, you don't show your LabVIEW code, but be aware that a CStr is not the same as an LPCSTR. The latter is a pointer to a constant string. Thus, the DLL is expecting a pointer to a memory location that contains a string that will not change.

---

For all practical purposes this should not be a problem. The opposite could be a problem since LPCSTR could be located in a write protected code segment and if the function then tries to access it with a write like operation, it will protection fault.

[Golziante]

Dear Labiew Users,

I'm quite tired and frustrated. The "Call Library Function Node" continue to return error and the .NET DLL is not good for me (or maybe I'm not good for .NET). Perhaps I will go to call an executable passing it some parameters. I will not be happy but It will work.  

In the meantime this morning I also try to don't call directly the dll but I called by means of LoadLibrary and FreeLibrary (I found the code here from Wiebe thanks).

The result is exactly the same (I know that is how It should be but I was curious to try that approach).   

Attached there is a jpeg showing front panel and block diagram and also the LabVIEW code.

Regards

Golzio

[smercurio_fc]

---

Golziante wrote: 

I'm quite tired and frustrated. The "Call Library Function Node" continue to return error and the .NET DLL is not good for me (or maybe I'm not good for .NET). Perhaps I will go to call an executable passing it some parameters. I will not be happy but It will work. 

---

What exactly is "not good for you"? Does it generate an error? Does it not perform the operations? As I noted, since you have a static class, you should not be wiring a .NET constant to the Invoke nodes. Thus, delete that little .NET constant that you have on your block diagram, and specify the class to use directly with the Invoke Node. 

As for the DLL, we can't run the DLL, so there's no way to test this. Have you verified that you're passing the correct values to the function? Like the correct password?