LabVIEW
Problem about GetHidGUID .... (Not Solved)
Solved!
vgbraymond wrote:I was really confused.
Firstly.. A guid should have 16 byte but I can store up to 8 byte (64bit) in one element, so my GUID here should be incomplete... How should I deal with this?
Secondly.. I got two elements at the first time, and then I tried to unplug my mouse and (I am using a notebook so I have my mouse pad) run this program again, I still got two elements in the array.. why would this happen?
Raymond
Firstly, you allocate an array of 16 int32, not 16 int8 (bytes), then you pass it to the Call Library Node to a parameter that has long long array type. long long however is 64 bits so LabVIEW converts your 16 int32 into 16 int64 to pass to the function. That function fills in 16 bytes and returns. I hope you can see why you get what you get.
Secondly the GUID returned is simply a GUID that you can use to enumerate the HID devices in your system. It is NOT the device enumeration itself. For that you need to do a lot more work in terms of calling several more Windows APIs among which some like SetupDiGetClassDevs(), SetupDiEnumDeviceInterfaces(), SetupDiDestroyDeviceInfoList() and HID_FindDevice().
glogloglo wrote:I am trying to enumerate HID devices too, but the function setupdienumdeviceinterfaces does not return anyone.
Can someone help me?
Thanks,
Andrew
Are you sure that the Wiimote registers itself as a HID device??? It could be but it could just as well be that it uses its own custom USB class.
And there are some problems with your VI. The hWndParent parameter to the SetupDiGetClassDevs is not a string but simply a pointer sized integer (32bit integer for pre LabVIEW 8.6) and should be a 0 value if you do not have a valid window handle.
Similar with the second parameter to SetupDiEnumDeviceInterfaces. You call it elements and pass an empty string to it. However it is a data structure and for them the only valid parameter is either a NULL pointer or a valid structure block. Passing in an empty string is NOT equal to passing in a NULL pointer. Either construct a valid data structure and pass its pointer to this parameter or reconfigure it to be a pointer sized integer and pass a 0 value to it. As it is now, the function interprets that parameter to be a valid structure but only the first byte of it is defined by LabVIEW and set to 0. All the rest is random and sure enough 99.999999% to define something that Windows can never find a device for.
And last but not least all these functions can fail. This is either indicated by returning INVALID_HANDLE_VALUE (-1 or 0xFFFFFFFF) for SetupDiGetClassDevs or FALSE (0) by the other functions. In that case you should generate an apropriate error and NOT call any other functions, except possibly the SetupDiDestroyDeviceInfoList if at least the SetupDiGetClassDevs was successful. Unfortunately since LabVIEW is multithreaded there is no way to retrieve the GetLastError() value in the case of a failure indication of either of these fucntions. So you onlyknow that an erorr happened but not which one. To really makes this whole thing robust and fully functions including getting meaningful erro codes from GetLastError() you would have to create an external DLL and implement everything in there and then call its API through the Call Library Node.
