what exactly is HTREEITEM?
in [Win32 API]
|
From: John Carson on 8 Dec 2006 20:56 "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 9 Dec 2006 13:46 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 9 Dec 2006 14:02 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 9 Dec 2006 14:32 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 9 Dec 2006 14:58 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
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: ERROR_PARTIAL_COPY on ReadProcessMemory() Next: Getting VID,PID of USB Device. |