Help me understand this C code

Question

INT GetTree (HWND hWnd, HTREEITEM hItem, HKEY *pRoot, TCHAR *pszKey, INT nMax) { TV_ITEM tvi; TCHAR szName[256]; HTREEITEM hParent; HWND hwndTV = GetDlgItem (hWnd, ID_TREEV); memset (&tvi, 0, sizeof (tvi)); hParent = TreeView_GetParent (hwndTV, hItem); if (hParent) { // Get the parent of the parent of the... GetTree (hWnd, hParent, pRoot, pszKey, nMax); // Get the name of the item. tvi.mask = TVIF_TEXT; tvi.hItem = hItem; tvi.pszText = szName; tvi.cchTextMax = dim(szName); TreeView_GetItem (hwndTV, &tvi); //send the TVM_GETITEM message? lstrcat (pszKey, TEXT ("\\")); lstrcat (pszKey, szName); } else { *pszKey = TEXT ('\0'); szName[0] = TEXT ('\0'); // Get the name of the item. tvi.mask = TVIF_TEXT | TVIF_PARAM; tvi.hItem = hItem; tvi.pszText = szName; tvi.cchTextMax = dim(szName); if (TreeView_GetItem (hwndTV, &tvi)) //*pRoot = (HTREEITEM)tvi.lParam; //original hItem = (HTREEITEM)tvi.lParam; else { INT rc = GetLastError(); } } return 0; } 

The code block that begins with the comment "Get the name of the element" does not make sense to me. If you get a listview item, why does the code set the parameters of the item to retrieve? If you already have values, there is no need to retrieve them.

Secondly, next to the comment, “original” is the source line of code that will compile with a warning under the built-in visual C ++ 4.0, but if you copy the same code in visual studio 2008, it will not compile. Since I have not written any of this code, and am trying to find out if it is possible that the author made a mistake on this line? * PRoot should point to the HKEY type, but does it distinguish the HTREEITEM type, which should never work, because the data types do not match?

Answer 1

The code block that begins with the comment "Get the name of the element" does not make sense to me. If you get a listview element, why does the code specify the parameters of the element to be extracted, because if you already have values, you won’t need to look for them.

After this comment, the first line indicates TreeView_GetItem (which, by the way, is actually an override of SendMessage), we want to get the text of the element and the associated lParam. The next line indicates the handle of the element about which we want information.

The next line indicates where the saved text should be saved, that is, in the szName buffer, which was allocated at the beginning of the function; the last line before calling the function determines the size of such a buffer, therefore, to avoid buffer overflow.

I suggest you look at the TreeView_GetItem and TVITEM documentation to better understand what is going on.

Secondly, next to the comment "original" is the source line of code that will be compiled using varning under the built-in visual C ++, but if you copy the same code in visual studio 2008, it will not compile. Since I did not write any of this code, and I'm trying to find out if it is possible that the author of the original was wrong on this line, since * pRoot should point to the HKEY type, but it goes over to the HTREEITEM type, which should never work with those then the data types do not match?

It is unclear what the code is trying to do there; at first glance, I would say that the lParam associated with each element in the root directory of the node tree stores a handle to the registry key, and the procedure receives it this way. However, if that were the case, then the action (HTREEITEM) would not make sense; it was probably a mistake forgiven by the compiler because it treated all the descriptors as plain void *; if my hypothesis is correct, you should keep the original string by simply replacing (HTREEITEM) with (HKEY).

Answer 2

Many times, API calls receive information in a structure, and also return information in the same structure. If you look at the documentation for TreeView_GetItem, it will clearly show how it works.

As for the second question, are you compiling it as C ++? What mistake?

Answer 3

The LPTVITEM parameter to the TreeView_GetItem macro is used bi-directionally.

TreeView_GetItem does send a TVM_GETITEM message to the tree view. What happens here is that the caller fills in a bit of structure to say “here, what I have and what I want,” and then the tree image fills in the requested bits.

From TreeView_GetItem documentation

When a TVM_GETITEM message is sent, the hItem member of the TVITEM or TVITEMEX structure identifies the item to receive information about it, and the mask member indicates the attributes to retrieve.

For the second part, I think it looks like it was an error based on variable names, etc., but you should probably check how the function is used in the rest of the code to make sure.

Answer 4

The first question is quite simple: you fill in a few elements in the structure to tell what data you want, and then call TreeView_GetItem to actually get the specified data. In this case, you specify TVIF_TEXT , which says that you want the text for a specific element. You also give him a buffer where he will put the text ( szName ), and tell him how long this buffer is (so that it will not write past the end of the buffer). When you call TreeView_GetIem , it copies the text for this element to your clipboard.

As for your second question: it looks like this code (both old and new) is somewhat problematic. The general intention is supposed to be to get the path to the element that was originally adopted, but that seems to be pretty bad. It begins with a recursive tree walk to the root. Then it extracts the text for the root element, but only to the local variable szName , which is then ignored (not copied to szKey ). It stores the handle to the root element in hItem (here it was originally written in pRoot ).

Then, when it returns ("back" down "tree"), it extracts the text for each element and adds these names to szKey (separated by "\") to form (most of) the path to the original element. Unfortunately, since he does this, he ignores the passed nMax , so he can (apparently) write over the end of the szKey buffer.