Question about SetWindowSubclass()
Vincent Fatica
"uIdSubclass
[in] UINT_PTR to subclass ID. This ID and the callback pointer uniquely identify
this subclass callback. Note: On 64-bit versions of Microsoft Windows this is a
64-bit value."
Is this thing really a pointer to an ID (as the docs say) or the ID itself?
If it's a pointer to an ID, then MSDN's example,
SetWindowSubclass(button, OwnerDrawButtonProc, 0, 0);
looks highly questionable ... probably not a good idea to de-reference 0 as a
pointer to find out what the ID is. And I have recently had success using
uIdSubclass = 66; apparently RemoveWindowSubclass() doesn't try to de-reference
it.
OTOH, if it's really the ID itself, the docs should not say "to subclass ID".
Reading the docs literally, I would expect uIdSubclass to be de-referenced to
determine the ID which partly identifies the subclass callback.
I have come to expect ambiguity whenever I see <TYPE>_PTR. Am I missing
something? Is there some way to tell if <TYPE>_PTR is really meant to be a
pointer to some useful information, or to be the information itself? If it can
be either, how am I to know which?
Thanks.
--
- Vince
Igor Tandetnik
news:46b1247c$1...@news.vefatica.net
> Of SetWindowSubclass()'s third patameter, the docs say:
>
> "uIdSubclass
> [in] UINT_PTR to subclass ID. This ID and the callback pointer
> uniquely identify this subclass callback. Note: On 64-bit versions of
> Microsoft Windows this is a 64-bit value."
>
> Is this thing really a pointer to an ID (as the docs say) or the ID
> itself?
UINT_PTR type is an unsigned int that is the same size as the pointer -
that is, 32-bit on Win32 and 64-bit on Win64 (as opposed to plain UINT
that is 32-bit in both cases). UINT_PTR is not a pointer.
> OTOH, if it's really the ID itself, the docs should not say "to
> subclass ID".
Clearly a typo. Or perhaps the proofreader also assumed that UINT_PTR is
a pointer, and "fixed" the wording.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
Vincent Fatica
>UINT_PTR is not a pointer.
Never, ever?
What about DWORD_PTRs? They are sometimes used as pointers (for example,
SetWindowsSubclass's fourth parameter), sometimes not (for example
SetThreadAffinityMask's second parameter). It's confusing.
--
- Vince
Igor Tandetnik
> On Wed, 1 Aug 2007 21:40:21 -0400, "Igor Tandetnik"
> <itand...@mvps.org> wrote:
>
>> UINT_PTR is not a pointer.
>
> Never, ever?
Well, you coud cast a pointer to UINT_PTR and pass it around this way -
in the same way you used to be able to cast a pointer to UINT.
> What about DWORD_PTRs?
DWORD_PTR is to DWORD what UINT_PTR is to UINT. DWORD and UINT are
typedefs for the same type; DWORD_PTR and UINT_PTR are too. Before you
ask why Windows headers sometimes use one and other times another, I
have no idea.
> They are sometimes used as pointers (for
> example, SetWindowsSubclass's fourth parameter)
No, the last parameter to SetWindowSubclass is not a pointer, but an
integer value. Again, you can cast a pointer to it (the size of
DWORD_PTR is guaranteed to be large enough for the cast not to lose
significant bits), but you don't have to. Whatever you pass here will be
forwarded to your callback intact (where you could cast it back to the
original pointer).
Vincent Fatica
>> They are sometimes used as pointers (for
>> example, SetWindowsSubclass's fourth parameter)
>
>No, the last parameter to SetWindowSubclass is not a pointer, but an
>integer value. Again, you can cast a pointer to it (the size of
>DWORD_PTR is guaranteed to be large enough for the cast not to lose
>significant bits), but you don't have to. Whatever you pass here will be
>forwarded to your callback intact (where you could cast it back to the
>original pointer).
Of course. That's how I use it. I guess I just don't like the names,
<TYPE>_PTR.
--
- Vince