DLL creation from existing project solution

[PhattieM]

Our lab group was provided with a VC++ project solution that builds (with a few warnings) .dll files. However, when these .dll files are built, we cannot access the functions from Labview. Can someone advise us on the additional changes that must be incorporated (step-by-step) in the .dll generation with already existing wrappers? Specifically using Visual Studio 2005? Also, if theres another method of accessing these functions from Labview we'd be glad to hear it. Thanks in advance.

Mark

[Aristos Queue]

> Can someone advise us on the additional changes that must be

> incorporated (step-by-step) in the .dll generation with already

> existing wrappers?

I've never seen a DLL that you couldn't invoke from LabVIEW. What sort of changes are you expecting that might be required? Are you getting any particular error code from LabVIEW when you try to make the DLL call that might shed some light on this?

NOTE: If you cannot find a trivial solution to this problem, you really should be posting to the DevZone Forums on ni.com. The AEs there have a better chance of answering this sort of question.

[PaulL]

This topic is of considerable interest to us as well. My understanding is there can be limitations. For instance (from Calling External APIs):

"Some APIs have structure and, in the case of C++, class data types. LabVIEW cannot use these data types. If you need to use a function that has a structure or class as an argument, you should write a CIN or shared library wrapper function that takes as inputs the data types that LabVIEW supports and that appropriately packages them before LabVIEW calls the desired function." See also these discussions:

using dll class-based, Struct to C++ dll. We encountered issues like this when trying to call a .dll built from C++. We gave up for the moment (but we're not great experts on calling dlls, so that doesn't mean it can't be done) and did something else. We'd love to know how to do this if there is a way....

Paul

[richlega]

There are two main problems that you are facing:

1. The name of the function needs to be exposed to the "outside world" so the linker can see it.

2. You need to see that the function name is not "mangled" (Microsoft calls this "decorated").

I am not familiar with the 2005 compiler, but I know that the earlier compilers have examples and/or code generators that will do both of these things.

It might be easier for you to create a new progect that exports the symbols properly and copy the code into them or use the generated code as an example to fix your existing code.

Regards,

rich

P.S. If you want, let me know and I will work up an example using the earlier version compiler.

[Rolf Kalbermatter]

QUOTE (PhattieM @ Jun 25 2008, 04:03 PM)

Our lab group was provided with a VC++ project solution that builds (with a few warnings) .dll files. However, when these .dll files are built, we cannot access the functions from Labview. Can someone advise us on the additional changes that must be incorporated (step-by-step) in the .dll generation with already existing wrappers? Specifically using Visual Studio 2005? Also, if theres another method of accessing these functions from Labview we'd be glad to hear it. Thanks in advance.

Mark

It's VC++ but which version? And also do you generate an ActiveX library or a function library instead. The first needs to be accessed from LabVIEW through the ActiveX nodes after the DLL has been registered on the computer on which it is to be used and you also need to make sure to create a type library for the DLL and include it in the registration.

If it is a functional library then there are a few things you need to take care of. First you cannot import C++ objects through the Call Library Node. This would be difficult to create but most important impossible to support since there is no binary standard how C++ objects are exported from a library. Each C compiler does it in a different way.

Instead you need to export every single method of the objects you want to access and write accessor methods for public data you want to access and export them too. Then you should make sure that your C compiler exports thos methods as standard C symbols to avoid name mangling c.q "decoration".

To tell a C compiler to export functions as Standard C symbols you either prepend the function declaration or implementation with extern "C" or surround all the exported function declarations between the

extern "C" {

your function1()

your function2()

etc.

}

Last but not least you need to make sure those functions really get exported from the DLL. This can be done by either creating a .def file that lists all symbols that you want to export or by adding the __declspec(dllexport) statement in front of each function declaration that you want to be exported. Other C compilers while nowadays often supporting the Visual C syntax use different declarators to mark symbols as being exported from a shared library such as attribute(export) that is for GCC and I believe Borland C used that too.

Rolf Kalbermatter

[PhattieM]

Well -- I know I'm going to break a lot of hearts but I did not try and get the .dll's to work for too long. Instead I found a .NET wrapper which I could call using the NET interface in LABVIEW. All of the above mentioned solutions do look like they would work, but I did not want to spend too much time on this small part of the project. Thanks for all your help!

Mark