Re: MFC and CD Drive

From:

"Tom Serface" <tom.nospam@camaswood.com>

Newsgroups:

microsoft.public.vc.mfc

Date:

Tue, 27 Mar 2007 23:15:22 -0700

Message-ID:

<13B9418D-FF05-4260-8A0D-CF2AB5554C9B@microsoft.com>

Hi MrAsm,

See below:

"MrAsm" <mrasm@usa.com> wrote in message
news:1s5j03p55gmvme83id367ntk794t2ag6oh@4ax.com...

Hi Tom,

I like your code, too.
(I just voted my 5 rating to you on CodeProject :)
Thanks for the articles!

I was just curious about this (and I would appreciate your opinion):

<CODE>
UCHAR buffer[2048]; // Must be big enough hold DEVICE_MEDIA_INFO
   ULONG returned;
   BOOL bStatus = DeviceIoControl(hDrive,
IOCTL_STORAGE_GET_MEDIA_TYPES_EX,NULL, 0, &buffer, 2048,
       &returned, NULL);

</CODE>

1. Why do you use UCHAR instead of BYTE?

Not sure. They both have the same storage capacity so I probably just
thought of it first. You're probably right since the result is really a
bunch of BYTES rather than UCHARS, but the effect is the same.

2. Is it good programming habit to prefix Win32 APIs with ::?
::DeviceIoControl(...)

I do that sometimes, but there is nothing conflicting with this name in any
of the MFC classes or other classes I am using so I didn't think it was a
big deal. I would, for sure, use that technique on something like a
::PostMessage() or ::SendMessage() call if I tried to call the SDK version.
Obviously, that's a matter of taste. Note that I didn't put :: on
CreateFile either :o)

3. Do you think that sizeof(buffer) instead hard-coded 2048 in
DeviceIoControl would be better? (So, if the programmer changes
'buffer' array size, he must not pay attention to also updating the
number in DeviceIoControl parameter?)

You are probably right. I've been using this code for a while and it works
so I just didn't change it. I may change that now that you point it out. I
pretty much just picked as size I knew would be big enough. The union in
question doesn't contain any classes that may have objects so sizeof would
likely work. I'll play with that in the morning when I am more awake :o)

4. Why the first article is tagged as "C++ (VC8.0)" and not also VC6?
(On the other side, the second article is tagged "C++ (VC6, VC7,
VC7.1, VC8.0)". I believe it works also on VC6...(I will test it.)

I don't have a copy of VC 6.0 loaded so I don't have a way to validate
whether or not the code works. I don't know of any reason why it wouldn't
though.

Thanks for your thought provoking questions. This is Version 1 of this code
so some changes are likely in order. I appreciate your comments and these
kinds of discussions are very helpful in this forum.

Tom