From: John Carson on
"Lucian Wischik" <lu.nn(a)wischik.com> wrote in message
news:ueljn2pn9mdphk0f7itv13p3em7irnpvpu(a)4ax.com
> "dan" <dagoldman(a)yahoo.com> wrote:
>> What exactly is HTREEITEM? commctrl.h says: "typedef struct _TREEITEM
>> *HTREEITEM;". Since I'm not getting any compiler error, I assume
>> "struct _TREEITEM" must be defined somewhere. But I could not find
>> "struct _TREEITEM" defined in any header file.
>
> I just tried some experiments...
>
> (1)
> typedef struct _lucian *HLucian;
> HLucian a;
>
> (2)
> struct newstructname *varname;
>
> (3)
> struct anotherstructname var2name;
>
> Numbers (1) and (2) compile fine in isolation. Number (3) fails with
> "var2name uses undefined struct anotherstructname"
>
> So I'd guess that C++ at least lets you define pointers to structs
> without defining the struct.

You will note that omitting the struct keyword from (1) and (2) causes them
to fail to compile, e.g.,

typedef _lucian *HLucian;

won't compile.

Using the struct keyword in the typedef or pointer declaration is similar in
effect to using a forward declaration, e.g.,

struct _lucian;
typedef _lucian *HLucian;

will compile.

--
John Carson


From: dan on
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.

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, and in anticipation of some additional tree controls I'm
going to be programming. What I've learned is:

A) WC_TREEVIEW comes first. CreateWindowEX is called with WC_TREEVIEW
class name to make a tree control. The returned HWND handle is used
thereafter to refer to the tree control. All subsequent operations to
the tree control and it's nodes are SendMessage messages. A lot of
messages (not listed) act directly on tree control, with no TVITEM or
HTREEITEM argument or return value, such as TreeView_GetCount.

B) HTREEITEM is the final reference to a tree node, and stays around as
long as the node exists. It's a handle, with some odd historical
difference in how it's defined. HTREEITEM also has some pre-defined
values: TVI_ROOT, TVI_FIRST, TVI_LAST, TVI_SORT. Most tree control
messages take HTREEITEM as an argument. I saw the following macros that
use HTREEITEM:

TreeView_CreateDragImage,
TreeView_DeleteItem,
TreeView_EditLabel,
TreeView_EnsureVisible,
TreeView_Expand,
TreeView_GetItemRect,
TreeView_GetNextItem,
TreeView_SortChildren,
TreeView_Select,
TreeView_SelectItem,

And the following return HTREEITEM:

TreeView_GetNextItem,
TreeView_HitTest,
TreeView_InsertItem,

C) TVITEM seems to be a temporary structure, or helper structure. I
imagine it might have been named better, to distinguish from HTREEITEM.
Use "HELPER" or "SCRATCH"? TVITEM is somewhat complex, with it's mask,
stateMask, and state members. TVITEM is filled in and used as a member
of TV_INSERTSTRUCTURE to add a node with TreeView_InsertItem, which
returns HTREEITEM. TVITEM is also filled in and its pointer passed to
TreeView_GetItem and TreeView_SetItem. But TVITEM has an HTREEITEM
member, so that's how Windows figures out which node to use. You have
to use a valid HTREEITEM in the TVITEM structure for TreeView_GetItem
and TreeView_SetItem to work.

Maybe the above is old hat to the experts. Please let me know if I got
anything mixed up, or something else I might need to know about this.

Thanks,
Daniel

From: Grzegorz Wróbel on
dan wrote:
> 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.

You're right. HTREEITEM is listed among Win32 Simple Data Types under
the same entry in MSDN:

HTREEITEM Handle to an item in a tree-view control.


--
Grzegorz Wr�bel
http://www.4neurons.com/
677265676F727940346E6575726F6E732E636F6D
From: Grzegorz Wróbel on
Grzegorz Wr�bel wrote:
> dan wrote:
>> 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.
>
> You're right. HTREEITEM is listed among Win32 Simple Data Types under
> the same entry in MSDN:
>
> HTREEITEM Handle to an item in a tree-view control.
>

Funny, signs of this handle seem to be missing in the current release of
MSDN (including online version) under Windows Data Types entry. I can
track it though in some ancient MSDN versions. I wonder when they've
lost it? I informed them of the missing entry.
Could you track in your offline MSDN versions if you have it?

--
Grzegorz Wr�bel
http://www.4neurons.com/
677265676F727940346E6575726F6E732E636F6D
From: Lucian Wischik on
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