Calling dll Help

[shivels]

Thanks for all your help Guenter, but now I'm really confused.  The company won't send me a c dll because the don't offically offer support for LabVIEW.  The dll does require extrenal hardware, but I'm just trying to get the vi to run without the errors and then build on that.  Smercurio_fc says I need to write a wrapper C dll?  I believe if I can call some of the functions, then that means the dll can work with LabVIEW, right?  Here is vpro32.dll?  I'm using LabVIEW 8.0, if this matters.  How was you able to figure out that those two functions were exported by the dll?

[GuenterMueller]

Dependency Walker is a great tool when dealing with DLLs.

[GuenterMueller · Accepted solution]

With the vpro32.DLL I am able to run your VI and reproduce the problem. The Visual Studio debugger says: "First-chance exception in LabVIEW.exe (XTAUTOLIB.DLL): 0xC0000005: Access Violation."
Now it's time that the originator of this DLL tells your more details, provides programming examples, and so on.
It is definitely not your job to guess what further actions need to be done before calling this function.
Regards, Guenter

[shivels]

Ok, thankyou for all of your help.  These fourms have helped me many times

[smercurio_fc]

Why are you using stdcall for the DLL? Did the vendor explicitly say that you're supposed to use stdcall as opposed to normal C-call? It's unusual for a "regular" DLL to use stdcall.

[rolfk]

---

smercurio_fc wrote:

---

Guenter Mueller wrote:
Although I met this statement ("LabVIEW cannot call C++ DLLs.") quite often I have to say that I have occasionally met DLLs created in C++ and as long as the functions in these DLLs use simple data types there is a good chance that they will work with LabVIEW.

---

See here: Building a DLL with Visual C++, especially Step 3. This is not new. If the DLL is compiled so that the functions names are not decorated then the DLL will work, even if it's compiled with a C++ compiler. However, LabVIEW will not be able to instantiate classes from the DLL. 

---

It is not the question if C++ or C was used to create the DLL in fact. The important part is that the DLL exports functions and not objects. The Call Library Node only can access exported functions but not C++ object interfaces. A C++ compiler can also create functions exported dirctly from DLLs when the according functions are prepended with the extern "C" specifier.

If all your DLL exports is however an object constructor and all the rest or the functions and functionality needs to be accessed through the object pointer then the Call Library Node can not deal with it.

Also the decoration of names is not really a problem, although it is rather annoying. The Call Library Node can import decorated names just as well.

Rolf Kalbermatter

[smercurio_fc]

---

rolfk wrote:

Also the decoration of names is not really a problem, although it is rather annoying. The Call Library Node can import decorated names just as well.

---

In the past I've always had problems with decorated names, so I've just stuck to the "use extern C" method when compiling with a C++ compiler.