Prev: Enhanced handling of USB Sticks and setting "HDD" Bit
Next: Assign label to a drive letter and notify the Shell to update its cache
From: Arny on 20 Apr 2010 21:48


On 21.04.2010 00:54, winapi wrote:
>> Some struct definitions (I think REBARINFO was one of them) have been
>> extended for Windows XP and Vista, so sizeof(<such a struct>) now
>> returns something different than it did with the old definition.
>> Depending on the version of Windows that you run the program on, this
>> might be a problem. Commctrl.h contains some constants that can be used
>> instead of sizeof() to keep compatibility.
>
> This is currently on XP. I did think about the point you made, "after" I had
> changed that
> data in the "commctrl.h" header. I was wondering if you might be able to
> tell me some
> of the problems that could possible appear with updates for
> "sizeof(REBARINFO)"?
>
> I have been trying to follow the MSDN rebar example currently, and it does
> not seem
> to look like the one in their picture. The toolbar seems to sit over the
> combo box obscuring it from view. Also I can't seem to size the rebar
> control, it just assumes the "width" of the window on creation, or something
> of that manner.
>
> Maybe this is something to do with the "sizeof(REBARINFO)"?
>
> Do you know of any "simple" working examples?
>
> Thanks.
>
>

Hey. You shouldn't change any of the code in commctrl.h. Let Microsoft
deal with it.

Define the correct platform target before including commctrl.h:
#define WINVER 0x0501
#define _WIN32_WINNT 0x0501
#include <commctrl.h>

And it works, just as it should. There will be no problems for future
updates for the struct, as long as you define the correct target OS
you're compiling on. Internally the OS will use the size of the struct
to detect the version you are targetting of Rebar. All indication shows
they will always grow in size to indicate newer versions.

SendMessage(hwndRebar, RB_INSERTBAND,
(WPARAM)-1,(LPARAM)(LPREBARBANDINFO)&rbbi) will return 0 if it fails,
nonzero on success.
The SDK explains this in detail for the RB_INSERTBAND message.
If you have installed the SDK version 6.0a and doesn't explicitly define
the target, 0x0600 is assumed. Just a heads up.

Get "ControlSpyV6" if you want to experiment with win32 controls, and
their messages. Very useful tool.

Have fun! :)

- RaZ
From: winapi on 21 Apr 2010 06:04
> Get "ControlSpyV6" if you want to experiment with win32 controls, and
> their messages. Very useful tool.
>
> Have fun! :)
>
> - RaZ

Thanks for the information.


From: Bob Smith on 21 Apr 2010 12:26
On 4/20/2010 9:48 PM, Arny wrote:
[...]
> Define the correct platform target before including commctrl.h:
> #define WINVER 0x0501
> #define _WIN32_WINNT 0x0501
> #include<commctrl.h>

To make this more readable, use the values defined in <sdkddkver.h> as in

#define _WIN32_WINNT _WIN32_WINNT_WINXP
#include <windows.h>
#include <comctrl.h>

Note that if any of NTDDI_VERSION, WINVER, and _WIN32_IE are not defined
up to the point at which <sdkddkver.h> is encountered (which is the very
first #include in <windows.h>) and _WIN32_WINNT is defined, the ones not
defined are then defined based on _WIN32_WINNT. Thus, if you are happy
with the choices made in <sdkddkver.h>, then the only one you need
define is _WIN32_WINNT.

For example,

#define _WIN32_WINNT _WIN32_WINNT_WINXP
#include <windows.h>

results in the equivalent of

#define NTDDI_VERSION NTDDI_WINXP (a.k.a. 0x05010000)
#define WINVER _WIN32_WINNT_WINXP (a.k.a. 0x0501)
#define _WIN32_IE _WIN32_IE_IE60 (a.k.a. 0x0600)

If for some reason you need to override one or more of the above
choices, simply define NTDDI_VERSION, WINVER, or _WIN32_IE explicitly
before invoking <windows.h> and the code in <sdkddkver.h> will respect
your choice and leave it unchanged.

Note that if you don't define _WIN32_WINNT, then the default values are
dependent upon the version of the SDK you have in effect (yikes!). For
example, I'm using version 7.0 which has defaults of

#define PSAPI_VERSION 1 (if not already defined)
#define _WIN32_WINNT 0x0601 (if _CHICAGO_ is not defined)
#define NTDDI_VERSION 0x06010000
#define WINVER 0x0601
#define _WIN32_IE 0x0800

These choices (along with the fact that they might change when you
upgrade your SDK!) should convince you that it's always a good idea to
define at least _WIN32_WINNT, and that moreover, doing so using a name
rather than a number makes it more readable.

--
_________________________________________
Bob Smith -- bsmith(a)sudleydeplacespam.com

To reply to me directly, delete "despam".
From: winapi on 21 Apr 2010 14:20
> These choices (along with the fact that they might change when you upgrade
> your SDK!) should convince you that it's always a good idea to define at
> least _WIN32_WINNT, and that moreover, doing so using a name rather than a
> number makes it more readable.

Thank you for the explanation.


First  |  Prev  | 
Pages: 1 2
Prev: Enhanced handling of USB Sticks and setting "HDD" Bit
Next: Assign label to a drive letter and notify the Shell to update its cache