Prev: Combine list view with a tab ctrl
Next: CWnd derived parent, owner draw reflection does not work
From: RB on 18 Feb 2010 22:44
you gave an excellent speculation and comments, as my following pasted debugger
data will illuminate. However I agree that they did poor docs since the docs are
written "for" the end user which should not be confused by them but rather be
understood. But as you said I found that holder of the itemID does have to be an
UINT and the reason shown with following debugger values

The lpDrawItemStruct->itemID is 4294967295

With ItemIndex declared as an int
the following code

ItemIndex = lpDrawItemStruct->itemID;

results in this
ItemIndex now equals -1 (and causes later code "not" to execute as needed)
But with ItemIndex declared as an UINT
the same code results in this
ItemIndex now equals 4294967295 (which is the value later code is looking for)
same as lpDrawItemStruct->itemID 4294967295

In summation if one wanted to test for the "empty list box negative value" as spoke
of in the docs I guess they would have to do this
if ( (int)ItemIndex == -1)
Thank you for the excellent answer and they should have had "you" write the
docs (or macros)

-------previous messages------------------------
"David Scambler" <aa(a)aa> wrote in message news:Xns9D247D5046CEFDavidScambler(a)203.50.5.233...
> "RB" <NoMail(a)NoSpam> wrote in
> news:OdTxapPsKHA.1352(a)TK2MSFTNGP06.phx.gbl:
>
>>
>> ugh well yes I gather the bit thing as I'm aware the sign bit, and the
>> msdn link he gave me was the same as my VC helps files which I was
>> quoting from to start with. My question was "why is the struct written
>> that way?" I.e. if it was designed to sometimes hold a negative
>> value....Why didn't they just make it an int ?
>>
>
> It is probably futile to speculate what they were thinking. But here goes
> anyway...
>
> <speculation>
>
> Valid itemIDs are indeed unsigned but they wanted to overload the field
> with a reserved "undefined" flag. I guess it is just sloppy documentation
> and/or imprecise specification. They could have defined a specific macro
> for ((UINT)-1) then "-1" would not have been mentioned. Defining the field
> as int would be inappropriate for the primary purpose of the field, namely
> to use it as a control index.
>
> </speculation>


From: David Scambler on 19 Feb 2010 03:04
As far as Microsoft documentation goes, this is just the tip of the
iceberg.

See Joe Newcomer's site:

http://www.flounder.com/msdn_documentation_errors_and_omissions.htm
From: Oliver Regenfelder on 19 Feb 2010 04:58
Hello,

First of all thanks for the question as I just ran into the same wall
recently.

RB wrote:
> In summation if one wanted to test for the "empty list box negative value" as spoke
> of in the docs I guess they would have to do this
> if ( (int)ItemIndex == -1)

I think the following is better:

if(lpDrawItemStruct->itemID == static_cast<UINT>(-1));

Reason:

Your code with (int)(ItemIndex) == -1 relies on the assumption that
UINT is actually mapped to the type unsigned int.

Best regards,

Oliver
From: Oliver Regenfelder on 19 Feb 2010 05:04
Hello,

David Scambler wrote:
> Valid itemIDs are indeed unsigned but they wanted to overload the field
> with a reserved "undefined" flag. I guess it is just sloppy documentation
> and/or imprecise specification. They could have defined a specific macro
> for ((UINT)-1) then "-1" would not have been mentioned. Defining the field
> as int would be inappropriate for the primary purpose of the field, namely
> to use it as a control index.

Then why do all CListBox methods take the item index as int variable?

Best regards,

Oliver
From: RB on 19 Feb 2010 08:58
Thank you that is a good point. It would appear that MS coders really designed
the UINTs in this structure to be used a "bit field" which explains why sometimes
it is referred to in some function parameters as a DWORD instead of UNIT.
But I agree with you, why do they use so many other references to it as int.
It would seem (in my humble novice narrow window of view) that they should
have just "stuck" with the bit field in all of their references and laid the other
types references to rest on this, and coded their support funcs accordingly.
Again thanks for the input.

---------previous messages-------------------------
"Oliver Regenfelder" <oliver.regenfelder(a)gmx.at> wrote in message news:61bc8$4b7e60da$54773fff$8664(a)news.inode.at...
> Hello,
>
> First of all thanks for the question as I just ran into the same wall
> recently.
>
> RB wrote:
>> In summation if one wanted to test for the "empty list box negative value" as spoke
>> of in the docs I guess they would have to do this
>> if ( (int)ItemIndex == -1)
>
> I think the following is better:
>
> if(lpDrawItemStruct->itemID == static_cast<UINT>(-1));
>
> Reason:
>
> Your code with (int)(ItemIndex) == -1 relies on the assumption that
> UINT is actually mapped to the type unsigned int.
>
> Best regards,
>
> Oliver


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Combine list view with a tab ctrl
Next: CWnd derived parent, owner draw reflection does not work