LabVIEW
Calling DLL in LabVIEW
Solved!
Sorry pointer sized integers are a LabVIEW 8.6 and higher feature. I was mistaken when I wrote it is 8.5 and higher.
Vanisp wrote:Hi,
Could you please give me an example as to how to make the return value of the CreateObject function to be a pointer sized integer.
That's written in any decent documentation to a DLL. If it is not, you can 99% sure assume that it is 32 Bit, since the programmer who wrote that DLL most likely never has heard about 64 Bit development yet.How do I find out if the DLL supports 32 bit or 64 bit?
And why do you create a wrapper function? Is it necessary for me to create a wrapper function in LabVIEW 8.5 in this regard.
To what are you refereing here? I haven't mentioned wrapper functions in any of my replies to this thread, so please give some more context so I could give you a meaningful answer.
Vanisp wrote:Hi Steven,
I do not have the Header file to import the library, I just have the Dll.
Thanking you,
Regards,
Vani
Do you have the documentation to the DLL? A header file is helpful and necesseray for the import library wizard but in most cases not suffisant to make sure that the Call Library Nodes are correct. In absence of a header file you can also just create the VIs and configure the Call Library Nodes yourself based on the documentation only.
To say it in another way: A C header file while helpful can not give you all the information you need to interface to a more than trivial DLL since the C syntax does not describe all important factors of calling a function. It only has enough information to guide the compiler to create the necessary code to call the function, but contains normally no information about the size of array and string buffers allocated, the way such buffers should be allocated nor quite a few other details that determine if your code crashes or not when calling that function.
There should be a documentation for each function describing all such things in more detail and that is where you have to go through each VI anyhow despite of using the import library wizard (if you had a header file), and make sure the LabVIEW code allocates such buffers properly and does everything else required, meaning you have to normally edit such created VIs manually anyhow.
So without proper documentation but with headers (and at least a sample showing how the code should be called) the job gets quit a bit more difficult with some things having to be checked by trial and error. But without documentation and without headers there is no good way to interface to a DLL without resorting to disassembly and reverse engineering, which many legislations nowadays actually see as highly illegal activity almost as bad as terroristic attacks.
There are several reasons to write a wrapper DLL.
The first one is when some or all of the functions take complex datatype parameters. LabVIEW can deal with all standard C dataypes as parameters but it can get tricky when you have structures, especially with embedded array and string pointers inside. For APIs that have such parameters it is a lot easier to write wrapper functions in C that translate between LabVIEW friendly function parameters and the actual complex C parameters.
Also callback functions is another area where you simply need a wrapper function to translate the callback function into a LabVIEW event of some sorts.
There are other reasons to create wrapper functions such as managing resources inside the DLL to make sure resources are deallocated properly after unloading the DLL, eventhough the user may have forgotten to call the close function.
Last but not least if any of above reasons is true I tend to wrap all the functions of an underlaying DLL into a more LabVIEW friendly interface anyways since having started the DLL anyway already, such is often not a lot of extra work.
