C / C++ / MFC

5-Feb-02 23:42

Has anyone ever used SetupDiEnumDeviceInterfaces? If so what the &%$#@ is the
"CONST LPGUID InterfaceClassGuid" parameter refering to? I have tried values from the "devguid.h" but I get nothing. SetupDiGetClassDevs works with GUID_DEVCLASS_PRINTER and others like it.

Has anyone ever found a generic way of enumerating devices and/or drivers on Win NT/2000. I'm just about to tear my hair out trying to find the device name for a USB printer.

Why does it have to be so hard??? Dead | X|

6-Feb-02 4:24

Joe Moldovan wrote:
Why does it have to be so hard???

Because you are going too fast. I've had a copy of 'Programming the Windows Driver Model' for about a month now and have reached page 44. (Well, I skipped over some of the hard to remember names - ever read Dostoyevski?).

You have plunged right into stuff that doesn't surface till page 62. But the key seems to be the call to SetupDiGetClassDevs. Check the docs on that.

If you would like to rant together, I suggest we start by whining about the fact that once we figure this out, we'll have to find out how NT does it... sigh...

6-Feb-02 8:15

Ah - this works:

HOWTO: Enumerate Hardware Devices by Using SetupDi Calls (Q259695)

Seems to work on NT as well - had to add the setupapi.lib to the linker settings, and, because I dropped the code into a .cpp file, cast a void * to char *.

Joe Moldovan6-Feb-02 9:27

6-Feb-02 9:27

Thanks for that.

But I need the bit with "Device Instance Handle, such as the Config Manager set of API functions, can use the DevInst value in the structure SP_DEVINFO_DATA returned by the SetupDiEnumDeviceInfo function" to work. And no, this call is not documented in the DDK any better than in the MSDN!

Hope you have fun persevering with the book.

6-Feb-02 10:48

Yes - I am starting to see the problem.

The USB devices are layered on top of the Root USB device. They won't appear in the list the sample retrieves.

I think in general the idea is that you know the name of the device you want to work with, and use the USBD_ fns or the IoBuildDeviceIoControlRequest call with the IOCTL_INTERNAL_USB_SUBMIT_URB type to get things going, and somehow identify the instance handle as a Device Extension to the USB device object.

As I google and grep one eyeball is making a concerted effort to crawl into the other socket - I realize now that we're dealing with more difficult stuff than I thought, and I hate posting msgs when I just _know_ I'm dealing with forces I cannot possibly comprehend.

But...

One thing you might find helpful on W2K is an examination of the keys in HKLM\SYSTEM\CurrentControlSet\Enum\USB. This should contain some sort of string for the printer driver - maybe something that can be used as the Enumerator param for SetupDiGetClassDevs - do the USB devs classify as PnP? (?).

I just don't see a generic USB device enumeration procedure, although some sort of use of UsbBuildGetDescriptorRequest might be able to do it.

Looks like working with USB devices is worth a book on its own - the WDM book I mentioned devotes a chapter to it, but at my rate I won't get there till... lets see... the time_t bug rears its ugly head...

Joe Moldovan6-Feb-02 20:12

6-Feb-02 20:12

For someone who says he doesn't know much you sure know a lot more about this stuff than me! Thank you for your very helpful tips.

The whole device/driver architecture/interface from MS is absolutely shocking. I have spent THREE whole days trying to do something which is trivial (send a "keep alive" null message every 5 minutes to a USB POS printer, an insignificant task for LPT1: or PRN: ) and I'm still scratching my head. But I did manage to answer the original question about SetupDiEnumDeviceInterfaces() parameters.

To help others struggling with this stuff, the "Pointer to a GUID that specifies the device interface class for the requested interface" mentioned in the ISDN, can be found in HKLM\SYSTEM\CurrentControlSet\Control\DeviceClasses. MS does not want us to access these directly but I have found no other way.

NOTE that there are a set of GUIDS which are the SETUP classes and are given in devguid.h. They won't work with this call but can be used in SetupDiGetClassDevs etc. as selectors for restricting the device data.

I am going to use IOCTL as per your suggestion. Who knows! In another ten years or so I might even understand all this.

7-Feb-02 4:25

Cool. I have printer off a copy of your reply which I hope I will understand someday.

Maybe you could resurrect this thread when you get things going - I'd be interested - my post was more of a 'well maybe its got something to do with' attempt than anything else.

Glad it helped! What a neat site.

Joe Moldovan7-Feb-02 9:35

Serialization, but not using MFC

7-Feb-02 9:35

I have solved my original problem. I will post a solution as a new thread because it has some very interesting implications for direct access to devices. As I suspected, the solution is grotesque but works very well.

5-Feb-02 23:33

Data persistence using the serialization mechanism provided by MFC is a very simple way of storing the data of a program. However, what happens if we don't want to use MFC!?? Does another mechanism exist that is just as easy to use?

My problem is that I am writing a program that will need to be used cross-platform and -OS, and so I am trying to get away from being too reliant on MFC (no matter how hard that may be making my life! Cry | :((

)

I suppose what I am asking is either this:
1) Has anyone else came up with an easy way to do this? Or (a more likely scenario...)
2) Has anyone got any information on how MFC actually serializes the data streams to file? What steps does it take to achieve this? And similarly, when reading the data back in.

Any help would be greatly appreciated!

Cheers! Wink | ;)

Baz

Baz

Re: Serialization, but not using MFC

Christian Graus6-Feb-02 0:19

Christian Graus

6-Feb-02 0:19

You need IOStreams. They work pretty much the same way, you can write IOStream handlers for any type and the whole thing is cross platform.

Christian

I have come to clean zee pooollll. - Michael Martin Dec 30, 2001

Picture the daffodil. And while you do that, I'll be over here going through your stuff.

Dynamically adding to toolbar

5-Feb-02 23:27

Hi,

I'm trying to dynamically add/remove buttons in a toolbar, and have used the AddButtons(...) function to do so. I need to process the toolbar messages by value (ie, call another function based on the value of the toolbar button) so I have overridden the OnCommand(...) function in the MainFrame. If I do it this way instead of adding a command handler for the message, I can never un-gray the toolbar button. I'm obviously overlooking something here... can someone help me out? Its very urgent!

Thanks a lot.

Jojo!

56789012346-Feb-02 0:38

5678901234

6-Feb-02 0:38

If your SDI program has not command message handler for menu/toolbar item, it remains disabled (Microsoft beleives this is better for us). To enable item you need to write it's ON_COMMAND handle or enable it in ON_UPDATE_COMMAND_UI handle.

Mazdak6-Feb-02 0:45

Mazdak

6-Feb-02 0:45

I think this will work:
If you add any function (like paste,undo and..) with class wizard you'll see
some codes add to your MESSAGE_MAP and header file ,you do the same for your dynamic toolbar then it'll ungray

Mazy

Don't Marry a Person You Can Live With...
Marry Someone You Can Not Live Without

6-Feb-02 0:51

Thanks for the replies guys. Maybe I didnt make it very clear in the original posting... but I have, say an array of max 256 buttons... and all of these are handled as such

OnCommand(...)
{
if (wParam >= ID_TOOLBAR_BTN_START && wParam <= ID_TOOLBAR_BTN_STOP)
{
DoSomething(wParam - ID_TOOLBAR_BTN_START);
}

OnCommand(...)
}

I dont think it'd be very good to add so many handlers to the window. My question is, is there any way to disable MFC's default behavior of disabling buttons if there is no handler. If someone could help me out, i'd be very very grateful.

thanks,
Jojo!

Mazdak6-Feb-02 2:02

Mazdak

6-Feb-02 2:02

MFC Hell;)

Mazy

Don't Marry a Person You Can Live With...
Marry Someone You Can Not Live Without

Fredrik Skog6-Feb-02 3:34

Fredrik Skog

6-Feb-02 3:34

Are you maybe looking for ON_COMMAND_RANGE ?

Cheers,

/Fredrik

Sonork ID: 100.11430:PhatBoy