QUOTE (Val Brown @ Jan 3 2009, 05:05 PM) Is this the kind of situation in which to use the DLL Wizard?
Well, theoretically. In practice the Windows API is sometimes very complex and the most difficult part is that it usually pulls in a very large part of the Windows header files and some of them do contain C preprocessor defines and C language constructs where the DLL Wizard parser simply chokes on. I've been writing a C header file parser in the past using LabVIEW and it was a major pain and still is not doing as much as the DLL Wizard parser can handle.
So even if the actual function you try to import is not using complicated parameters it is quite possible to fail due to the pulling in of other Windows API headers that are undigestable for the parser.
And if it is using complicated parameters then it will fail a lot of times anyhow.
QUOTE (mattdl68 @ Jan 3 2009, 03:38 PM) Hi Irene. Thanks for the info.
I looked into doing a wrapper. But i don't Know c that well. I was trying also to use the VISA develoment wizzard. The wizzrd had errors trying to setup the setapi.dll.
The VISA wizard is not about helping you call DLLs but about creating inf files for accessing VISA devices including USB devices. However for USB devices they should not be handled by an already installed or standard Windows driver as then VISA can not gain access to it.
You probably meant the Shared Libary Import Wizard and here you obviously need to point it to the right header file. In the case of the SetupDi... functions this would be the SetupAPI.h. Functions not defined in there but being exported by the SetupAPI.DLL (all the CMP_ and CM_ functions in your other screen shot) will of course cause errors but should not affect the SetupDi.. functions. However it all could still fail due to unparsable constructs in the SetupAPI.h file or in other depending header files.
QUOTE Correct me if i"m wrong, even using c++ you need to know thr order in which to call the functions. For example...say i want to find all devices currently connected to the USB? What is the order of doing that? i'm assuming there are some outputs of some functions that feed the inputs of other funtions.
Is ther some documation for this?
Yes MSDN and the Windows Platform SDK. MSDN is mostly about the function prototype and documentation and the Platform SDK (PSDK) contains both the headers and C code samples how these functions can be used.
QUOTE the SetupDiGetClassDevs asked for a flag, Dword. DIGCF_ALLCLASSES is one of the fags. Is this a string?
The flag ClassGuid is it a key which looks in the Ini file supplied by manufactuer. To get the device id (number)
but seeing for know I what all devices connected. This should be set to null. So would I input a string constat(null) or a 0(U32)
Since the flag is a DWORD it must be a integer number or bit flag. What numeric value corresponds to the Preprocessor symbol DIGCF_ALLCLASSES you can sometimes lookup in MSDN and otherwise you have to search in the headers of the PSDK for it.
A GUID is a structure of 16 Bytes length as you seem to have been told already. This and anything else about datatypes can be also found on MSDN or in the headers of the PSDK.
The function expects a pointer to that. If you need to pass here a NULL value you would configure it as uInt32 (or (Un)Signed Pointer-sized Integer in LabVIEW >= 8.6 which will take care about adjusting for the different pointer size if you ever move to LabVIEW for Windows 64 bit) and then pass in a 0 integer.
QUOTE (Val Brown @ Jan 3 2009, 08:14 PM) It is impressive to me how frequently that Wizard simply fails. Welcome to DLL Hell.
Ever written a C compiler?

Try and you will understand!
I admire the courage of the person not only attempting the task of creating the DLL Wizard (I've written a somewhat less exhaustive C header parser in LabVIEW for another project) but also adding it to the released version of LabVIEW. How it got past the release manager I'm not sure but that person probably had no idea about how difficult a good C parser is, so he or she believed it to work fine after being shown some successful imports from not to complicated APIs

.
Since it will be almost impossible to remove that tool now, it will stay there but I'm not sure there will be enough support for it once the father of this project moves on to other tasks.
Rolf Kalbermatter