LabVIEW
C++ & dll & labview
@simon76 wrote:Hi all,I have C++ dll & header file provide by one of the instrument company.By using labview, I able to call several function from the dll but not all that show in the header file. Can someone help me??Attach with the header file, only able call for the Global Function Declarations but not those API classes.Thanks and Best Regards,Simon
It's not surprising that you can not import most of those functions using the Import Library Wizard. Most of them do use C++ object pointers as parameters and the Import Library Wizard as well as LabVIEW does not know how to deal with them.
I have not looked at the details of this API but if you do not need to access any methods of those C++ objects from LabVIEW and also do not need to create and destroy those objects in LabVIEW (meaning the instantiation and deallocation of those objects is done in the DLL functions itself) you could simply treat those C++ object pointers as uInt32 and pass them from one API function to the other. However if you do need to instantiate [ new()] and dispose [ free()] them yourself or access any of the methods or public variables of those objects, there is absolutely no way around writing an extra wrapper interface for those objects, that exports C functions that do these things for you to be imported in LabVIEW.
It's not nice but there is simply no way that LabVIEWs Call Library Node interface could support that at all. It would be not only a pain in the ass for the person needing to configure those Call Library Nodes since they would need to know things most C/C++ programmers never even worry about, in order to tell LabVIEW how to do it right, but C++ object interfaces are simply not binary compatible between different C++ compilers so it's an exercise in vain anyhow.
Rolf Kalbermatter
Message Edited by rolfk on 05-04-2008 04:39 PM
Yes in that case you will have to use a C++ compiler in order to write a wrapper DLL that exports accessor functions for those puclic variables and any object methods you want to call. As far as LabVIEW's Call Library Node is concerned you will treat those C++ object pointers simply as an uInt32 variable.
@simon76 wrote:
I do need to access the public variables of those objects e.g call the handles..since i not master yet in C++ but from your reply, it's impossible to call those function except used the C++ compiler?
Make sure to export those functions as standard C functions though by embracing their function declarations with a
#ifdef __cplusplus
extern "C" {
#endif
your function declarations here
#ifdef __cplusplus
}
#endif
Rolf Kalbermatter
Message Edited by rolfk on 05-05-2008 07:47 AM
It's nothing special but simply a DLL that exports an API that is more LabVIEW friendly and calls your other DLL. It can translate between LabVIEW friendly parameters and the other DLL's complex parameters. And it would for instance export C functions that call the C++ object methods and access the public C++ object variables.
@simon76 wrote:wrapper dll is new for me. How it work?? Any examples or good reference link that i can refer to??thanks and regards,Simon
Any example that uses a DLL to access more complex OS API functions is in fact such a DLL too.
Rolf Kalbermatter
You sure have still a lot of learning C to do before you can hope to interface that DLL to LabVIEW.
@simon76 wrote:
I have go through the examples, in order to write wrapper dll, may need to have the source-code.
But I do not have the C++ code here, so what i can do is to modify the header file, am i correct??
No you do not need the C source code of the DLL in order to write a wrapper DLL, and no you do not modify the header file of said DLL.
Instead you write a C source file that includes that header file in order to tell the C compiler how to compile your code correctly to interface to that DLL. You should also write an additional header file that declares the additional C functions your DLL implements. That way you can then use this new header file with the Import Library Wizard to let LabVIEW create VIs to access those new DLL functions too.
How much time do you have? And are you sure you do not want to hire someone who does already know these things and is hopefully versed in external code in LabVIEW too? It would certainly reduce the time to get something working and increase the chance that it is working right. Interfacing to external code in LabVIEW is no easy business and the most tricky part is that it is not necessarily correct once it doesn't crash anymore. You still can have memory leaks, undetected memory corruptions and such and they can stay dormant in your app until one day you happen to do a small change in some seemingly unrelated part and suddenly BOOM.
Rolf Kalbermatter
Message Edited by rolfk on 05-06-2008 07:59 AM
