Win32 SDK Data Types

[sodlb]

Hi...Friends

Im Using 8.0 version , can i get LabVIEW equivalent Data types for all Win32 SDK  Data types....

I have got some list of these in the path ". ..\National Instruments\LabVIEW 8.0\examples\dll\data passing\Call Native Code.llb"....

But the functions what im using have other data types such as LPHWAVEOUT,HWAVEOUT etc..

can i get complete list of all these data types equivalent data types in LabVIEW....

Thanks and Regards,

SODLB

[DuffmanSays]

Hello SODLB,

Unfortunately there is no document that would describe all of the hundreds of data types used in the Win32 SDK and how these would map to LabVIEW types. In fact, most of these are not even standard C data types. However, most of them can be associated with a particular C type and thus the LabVIEW type can be inferred. The best resources for determining these data types are the SDK documentation and the windef.h for the type’s #define or typedef statement. You might also want to take a look at the Calling the Win32 SDK application note which further discusses the Win32 SDK as well as some discussion of data types. I hope this is useful for you!

Mike D.
National Instruments
Applications Engineer

[rolfk]

---

@duffman Says: wrote:
Hello SODLB,

Unfortunately there is no document that would describe all of the hundreds of data types used in the Win32 SDK and how these would map to LabVIEW types. In fact, most of these are not even standard C data types. However, most of them can be associated with a particular C type and thus the LabVIEW type can be inferred. The best resources for determining these data types are the SDK documentation and the windef.h for the type’s #define or typedef statement. You might also want to take a look at the Calling the Win32 SDK application note which further discusses the Win32 SDK as well as some discussion of data types. I hope this is useful for you!

Mike D.
National Instruments
Applications Engineer

---

Actually there is such a document. It's the Windows SDK headers but it is not one single document but a few hundred header files. msdn.microsoft.com is also a good place to find that information although finding datatypes can be sometimes difficult, but if you know a function that uses such a datatype then you get there usually quite fast.
Of course these are C header files and that means you need some fair good understanding about the C language and its datatypes but it is the only reference that is actually complete about the Win32 API at all. Forget about an even remotely complete Win32 to LabVIEW map reference. It would be a project that nobody can, wants and wishes to do, always lacking somewhere, quite likely wrong in places and last but not least necessarely incomplete due to the fact that certain C constructs are simply impossible to directly recreate in the LabVIEW Call Library Node.

The datatype the original poster mentions is however a pointer to a structure. Pointer because of the LP in the beginning with L standing for LONG and P for POINTER. The LONG here has historical reasons from Win3.1 where you had near pointers that could only address 64k of memory and far pointers (this where the long pointers) that could address larger memory areas (but if you wanted to access more than 64k in one go you still had to do some extra hokuspokus when accessing it). In Win32 there are no far pointers anymore and the near pointers have a linear address space of 4GB (but normally actually 2GB) so LP datatypes and P datatypes really are the same in Win32. The rest is a structure that contains a number of values and to map a structure into a LabVIEW datatypes requries really some C understanding. Also if the structure contains other things than skalar datypes (single integers and floats) it gets messy or even practically impossible to map that into a compatible LabVIEW datatype.

The other datatype HWAVEOUT is a handle. Handles in Windows and most other environments are opaque datatypes. That means they should be treated as an uInt32 as far as the caller is concerned and anything about the internal meaning of that handle is ABSOLUTELY private to the component that implements the functionality for the resource associated with that handle. Sometimes it is a pointer but quite often it is just an index into a resource specific global array somewhere internal to the API and you have no way to get to the actual information at all about this handle other than using the provided API functions.

Last but not least are alignment issues you need to consider for structures. Win32 uses for most of the APIs 8 Byte alignement but there are exceptions that you need to take from specific #pragma directives in the header files. LabVIEW uses byte packing, meaning it does no alignment and that is actually good so because you can interface a non-aligned environment to an aligned one by adding filler elements, whereas the opposite is not possible.

All in all this is a difficult matter and you really should learn a bit about C in order to make the more complex cases work at all. Without C knowledge you won't get far about interfacing to external shared libraries and with that knowledge the MSDN website and the Windows SDK headers are all you really need. With that knowledge you will be able to determine what you have to do and also will certainly sometimes come to the conclusion that interfacing certain APIs through the Call Library Node is almost impossible or at least so involved that writing a wrapper DLL that translates between this API and more LabVIEW friendly datatypes it the right thing to do.
Without the knowledge how to write that wrapper DLL you can simply forget to even dream about going to solve such complicated API interfaces completely in LabVIEW and once you have that knowledge you will recognize that writing that wrapper is much easier than trying to do it all in LabVIEW.

Rolf Kalbermatter

Message Edited by rolfk on 04-14-2007 09:32 PM

[Ken123]

Can anyone here tell me for sure that I am wasting my time?  I have a system that acquires data and creates specific audio tones.  I have a usb to midi converter and a midi sound device.  I can create audio tones (notes on/off) over the usb to midi with labview just fine using a midioutshortmsg call library function to the winmm.dll.  There is a bunch of setup commands that I would like to send to the midi tone generator using labview that I am currently doing manually.  The problem is that these setup commands fall into a category of midi called system exclusive messages because they can be different based on the manufacturer and user programmable features.  Built into the win api is a way to send midi system exclusive commands using the MidiOutLongMsg, MidiOutPrepareHeader and MidiHDR.  I'm not a good C programmer so I am struggling to figure out how to do this.

Here is the definition for MidiOutLongMessage

http://msdn2.microsoft.com/en-us/library/ms711629(VS.85).aspx

I am hoping that the datatypes will match up in Labview.

MidiOutLongMsg & MidiOutPrepareHeader

HMIDIOUT     hmo                   (signed 32 bit integer)
LPMIDIHDR   lpMidiOutHdr     (signed 32 bit integer)
UINT               cbMidiOutHdr    (unsigned 32 bit integer)

Before you send the MidiOutLongMsg you have to fill a buffer up with all the system exclusive commands that you want to send.  I'm pretty lost at this point.  I know the commands that I want to send because they are all listed in the manual for the synthesizer.  How do you create a buffer area using Labview that can be pointed to in the win api?

http://msdn2.microsoft.com/en-us/library/ms711592(VS.85).aspx

The MIDIHDR structure defines the header used to identify a MIDI system-exclusive or stream buffer.

typedef struct midihdr_tag { 
    LPSTR      lpData; 
    DWORD      dwBufferLength; 
    DWORD      dwBytesRecorded; 
    DWORD_PTR  dwUser; 
    DWORD      dwFlags; 
    struct midihdr_tag * lpNext; 
    DWORD_PTR  reserved; 
    DWORD      dwOffset; 
    DWORD_PTR  dwReserved[4]; 
} MIDIHDR, *LPMIDIHDR;