Adding new flags?

[Igor Tarasov]

Hi there!

I try to implement as precise as possible one undocumented feature in
comctl32, this all deals with one structure field. After lots of
testing I know the following:

1. Default value for that field returned by getter is 0.
2. By default it is ignored in behavior.
3. If you change value by the setter, even to 0, behavior changes.
4. Negative values, such as (-1) also produce different behavior and
cannot be used as "field not changed" flag.

So, does that mean that I have to add new flag to the structure that
would be set only if that field is changed, or there is another way to
do that?

[Nikolay Sivov]

Igor Tarasov wrote:
> Hi there!
>
> I try to implement as precise as possible one undocumented feature in
> comctl32, this all deals with one structure field. After lots of
> testing I know the following:
> - Default value for that field returned by getter is 0.
> - By default it is ignored in behavior.
> - If you change value by the setter, even to 0, behavior changes.
> - Negative values, such as (-1) also produce different behavior and
>
> cannot be used as "field not changed" flag.
>
> So, does that mean that I have to add new flag to the structure that
> would be set only if that field is changed, or there is another way to
> do that?

What flag are you speaking about? Toolbar stuff?

[Igor Tarasov]

2009/4/10 Nikolay Sivov :
> Igor Tarasov wrote:
> > Hi there!
> >
> > I try to implement as precise as possible one undocumented feature in
> > comctl32, this all deals with one structure field. After lots of
> > testing I know the following:
> > - Default value for that field returned by getter is 0.
> > - By default it is ignored in behavior.
> > - If you change value by the setter, even to 0, behavior changes.
> > - Negative values, such as (-1) also produce different behavior and
> >
> > cannot be used as "field not changed" flag.
> >
> > So, does that mean that I have to add new flag to the structure that
> > would be set only if that field is changed, or there is another way to
> > do that?
>
> What flag are you speaking about? Toolbar stuff?

Yep, it's about undocumented feature of iBitmap controlling buttons'
size But it works only if cx is zero and iBitmap was not specifically
set.

[Nikolay Sivov]

Igor Tarasov wrote:
> 2009/4/10 Nikolay Sivov :
> > Igor Tarasov wrote:
> > > Hi there!
> > >
> > > I try to implement as precise as possible one undocumented feature in
> > > comctl32, this all deals with one structure field. After lots of
> > > testing I know the following:
> > > - Default value for that field returned by getter is 0.
> > > - By default it is ignored in behavior.
> > > - If you change value by the setter, even to 0, behavior changes.
> > > - Negative values, such as (-1) also produce different behavior and
> > >
> > > cannot be used as "field not changed" flag.
> > >
> > > So, does that mean that I have to add new flag to the structure that
> > > would be set only if that field is changed, or there is another way to
> > > do that?
> >
> > What flag are you speaking about? Toolbar stuff?
>
> Yep, it's about undocumented feature of iBitmap controlling buttons'
> size But it works only if cx is zero and iBitmap was not specifically
> set.

So (-1) for iButton is reserved for not using imagelist bitmap at all 
and in some places this value checked for <0 instead of
== -1, right? Does it apply for separators only? If not maybe it's 
better to add something like BOOL IsiBitmapValid.
Let's get another opinions. (Hope you'll be ready with patch for today 
release)

[Igor Tarasov]

2009/4/10 Nikolay Sivov :
> So (-1) for iButton is reserved for not using imagelist bitmap at all and in
> some places this value checked for <0 instead of
> == -1, right? Does it apply for separators only?

Yes, separators only. If you set it to ANYTHING (even 0 and -1) it
affects the way toolbar is displayed.
> Let's get another opinions. (Hope you'll be ready with patch for today
> release)

I think I'll hardly do that. The more I dig into comctl code (right
now it is toolbar) the more bugs I find. There are tons of them :) And
sometimes it's not clear which one causes problems and which should be
fixed first, and how to split it into separate patches.

[Dmitry Timoshkov]

"Igor Tarasov"  wrote:
> So, does that mean that I have to add new flag to the structure that
> would be set only if that field is changed, or there is another way to
> do that?

First thing to do (as usually) is write a bunch of tests and get them
committed.