LabVIEW
Import DLL
Solved!
The .lib file has no function in combination with LabVIEW. When you start the Import Library Wizard you get in one of the first few wizard pages a text box labeled Additional defines or something similar. In there you have to enter the text as explained in the earlier post, possibly extended with additional Windows API defines. The example I posted was specific to the header file there.
As I’m traveling with no computer access for now I can’t look in detail at your specific header but from a brief glance there might be other bears hidden in this API that may make calling quite a few functions from LabVIEW beyond what the Import Library Wizard can do for you. As I have eluded to before in other threads, that Wizard is despite its name no magician and the C syntax in header files simply is not strong enough to define all aspects of a function call. Some information often needs to be extracted from the prosa API documentation and applied by the programmer itself. An automated tool can’t do that!
One of the problems is, that your support person is talking out of his or her neck. Pascal has nothing to do with this problem and the header file you provide is clearly for C/C++. Pascal was a programming language used in the 80ies and 90ies of last century and has no real meaning nowadays, even though I consider it a good language to start learning programming. pascal was also a calling convention for DLL functions in 16-bit Windows 3.x but doesn't exist in Windows 32-bit and 64-
bit at all.
The includes you list are:
stdafx.h: this is an include that the Visual Studio compiler creates when you create a project that does all kind of header magic and stuff and makes sure the standard object library is available and what else. It is always the first file I delete after creating a Visual Studio project. It has absolutely no meaning in combination with LabVIEW and only makes the thing more confusing.
mklib.h: this is the include file for the library. This is the file you will point the import library wizard to, when trying to import the DLL.
Now mklib.h does use several different Microsoft Windows API defines. These need to come from somewhere. In a typical C program and with the Microsoft SDK headers installed they can be referenced by a simple #include "windows.h" statement at the beginning of the source file.
While you could do that in the import library wizard by defining the "windows.h" include in the Include Paths list, this is pretty cumbersome and complicated by the fact that " windows.h" is just a top level include file that includes many more files in several subdirectories. It also requires you to have a Windows SDK installed on your machine, which is a pretty big download and installation.
More straightforward, although a little cumbersome in other ways than getting the SDK installed, is to simply define the missing defines yourself in the Preprocessor Definitions text box in the Wizard.
This will make the import library wizard happy enough to create wrappers.
BYTE=unsigned char; WORD=unsigned short; DWORD=unsigned long; LPCTSTR=const unsigned char*; LPTSTR=unsigned char*; WCHAR=unsigned short;
BUT!!!!!!!
There are several assumptions. LPCTSTR and LPTSTR are Microsoft defines for strings that can be either 8-bit ANSI strings or 16-bit Unicode strings. It is technically a very bad idea to use this type in a DLL API as the definition of this type depends on the settings of the project that calls this library while the compilation of the DLL was done with the settings for the compilation of the DLL. It is obvious that these can badly mismatch as the caller has no control and not even knowledge about how the DLL was compiled. Neither can the DLL programmer obviously know how the project that will call his DLL, will be defined.
Also this Wizard is not a magician! Calling DLL functions involves generally more than can be described in the C syntax in a header file!
So after the Wizard has created the VIs, someone with a sound understanding of C programming in general and the API in question in special, needs to go through each of the VIs to check it if it does call the function properly. The fact that LabVIEW does not crash when you call the created VIs is absolutely no guarantee that the VI is correct!
If you can't do that, get someone who can! If you don't, not calling such an API is much better than trying anyhow and creating a piece of software that may seem to work, but silently (or not so silently) will corrupt memory during execution.
