LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

how to call LabVIEW dll from ATL COM dll

I have tried to call simple LabVIEW 8.6 Dll from win32 test application, class Library.
I have include LabVIEW generated

SharedLib.h file and SharedLib.lib file in the test application which I created as simple win32 console project and also from win32 class Library. I was sucessfully able to call my LabVIEW dll funtion.

 

But when I create ATL COM project and try to add SharedLib.h file and SharedLib.lib file I used to get following erors

Error 1 error C2733: second C linkage of overloaded function 'StrCatW' not allowed d:\program files\national instruments\labview 8.6\cintools\extcode.h 463 
Error 2 error C2733: second C linkage of overloaded function 'StrCpyW' not allowed d:\program files\national instruments\labview 8.6\cintools\extcode.h 464 
Error 3 error C2733: second C linkage of overloaded function 'StrCpyNW' not allowed d:\program files\national instruments\labview 8.6\cintools\extcode.h 465 
Error 4 error C2733: second C linkage of overloaded function 'StrCmpW' not allowed d:\program files\national instruments\labview 8.6\cintools\extcode.h 466 
Error 5 error C2733: second C linkage of overloaded function 'StrCmpNW' not allowed d:\program files\national instruments\labview 8.6\cintools\extcode.h 467 

these many errors.

 

Will some one explain me how to call LabVIEW dll from ATL COM dll.

 

Thanks & Regards,

Jay

0 Kudos
Message 1 of 4
(3,865 Views)

Seems that your compiler (resp. linker) tries to link a function and an overload of the same function,

both with C linkage (sounds confusing and is confusing so your compiler complains:-)

ATL is C++ but your LabVIEW built DLL must be called as plain C.

I'd assume that the LabVIEW DLL wants the non-overloaded function but ATL wants the overloaded one.

That seems to be the reason for the clash...

 

You could to call the function in your LabVIEW built DLL via function pointer:

Load the DLL with LoadLibrary() and use GetProcAddress() to get a pointer to the function.

After you're done, unload the DLL with FreeLibrary() .

This way you don't have to link against SharedLib.lib .

Don't include the LabVIEW built header file SharedLib.h, just extract the parts you need.

If you have structures as parameters, remember to use #pragma pack.

Good luck!

 

Message Edited by candidus on 06-29-2009 09:17 AM
0 Kudos
Message 2 of 4
(3,806 Views)

I also had this problem.  My application is unicode-aware, but I was attempting to link it to a library with primitive C-string arguments.  You could dynamically load the DLL as suggested (more work), modify the header files (really not recommended), or if you are feeling lucky you could try fooling the compiler, as I was successfully able to do in Visual Studio 2010, by steering the preprocessor around those functions (assuming you're not using them, of course -- otherwise this probably wouldn't work):

// prepare for NI extcode.h inclusion. avoid linker errors for this project.
#define StrCatW(a,b)     IgnoreLinkError_StrCatW(a,b);
#define StrCpyW(a,b)     IgnoreLinkError_StrCpyW(a,b);
#define StrCpyNW(a,b,c)  IgnoreLinkError_StrCpyNW(a,b,c);
#define StrCmpW(a,b)     IgnoreLinkError_StrCmpW(a,b);
#define StrCmpNW(a,b,c)  IgnoreLinkError_StrCmpNW(a,b,c);

// header file for my LabView-built DLL (ASCII single-byte character arguments)
#include <MyLibraryHeader.h>

// clean up afterwards, put things back to 'normal'
#undef StrCatW
#undef StrCpyW
#undef StrCpyNW
#undef StrCmpW
#undef StrCmpNW

Message 3 of 4
(3,050 Views)

Thank you thank you thank you!  With minor modifications for LV2017 and Visual Studio 2015, this idea worked for me.

0 Kudos
Message 4 of 4
(1,425 Views)