From: Somebody on
HTREEITEM (along with every other handle type) is a HANDLE to an internal
Windows structure. It has nothing to do with MFC. Since these are INTERNAL
Windows structures, they are essentially a VOID pointer to the outside
world.


"Lucian Wischik" <lu.nn(a)wischik.com> wrote in message
news:j85mn2h6ea5ur95mc44l2f6gvoeeri0stl(a)4ax.com...
> Grzegorz Wr�bel </dev/null(a)localhost.localdomain> wrote:
>>Funny, signs of this handle seem to be missing in the current release of
>>MSDN (including online version) under Windows Data Types entry.
>
> That's why I had trouble finding it! I did Search>FindInFiles to scan
> the entire VC include directory for it. In the search results there
> were lots of results in "afxcm.h", part of MFC, hence my mistake.
>
> --
> Lucian


From: Sten Westerback (MVP SDK) on

"dan" <dagoldman(a)yahoo.com> wrote in message
news:1165690019.705615.99510(a)80g2000cwy.googlegroups.com...
> Lucian Wischik wrote:
>> Yes, there must be historical reasons. Isn't HTREEITEM part of MFC
>> rather than part of win32? I'm didn't even realise that MFC used
>> opaque handle types until I looked up HTREEITEM in relation to your
>> problem. Maybe the historical reason is that win32 always uses
>> DECLARE_HANDLE, but MFC does things its own way.
>>
>> --
>> Lucian
>
> Someone more expert than me needs to confirm, but it seems to me that
> HTREEITEM is part of win32 C API, since HTREEITEM is an argument or
> return value to so many C API functions. But I know little or nothing
> about MFC.

As someone pointed out already it is a "handle" type value and you need not
know what it "contains" in each version of Windows.

> The reason I originally posted was trying to exactly understand
> HTREEITEM and TVITEM, in my efforts to figure out a little problem I've
> run into,

Just a tought, would you care to tell us about that specific little problem
in case it is a problem that have some relevance to the HTREEITEM handle? :)

- Sten