You didn't paste in the error message you are seeing. commctrl.h contains this typedef: typedef struct _TREEITEM *HTREEITEM; This is why you are seeing _TREEITEM in the diagnostic.
I'm just guessing: Make sure that something important isn't being exclude because there is a #define WIN32_LEAN_AND_MEAN in your source code. Wizard generated projects put this in stdafx.h.
I can confirm that the use of typedef _TREEITEM {}; solved that problem.
I have not tried fiddling with the Lean and Mean def's as it seems inconsistent to do so. If afxcmn.h is included then the typedef above should occur regardless.
The code uses #define VC_EXTRALEAN - it is quite diverse, but is mainly client side DBMS using ODBC with common controls.
The problem is because struct _TREEITEM{} is not defined in the common control header files. To fix the problem define the following in your stdafx.h
struct _TREEITEM {};
More info: HTREEITEM is defined as typedef struct _TREEITEM* HTREEITEM; for typesafety.
In native C++, not having struct _TREEITEM define is not a problem, but the CLR needs an actual definition for a type even when just creating a pointer to it.
Use of HTREEITEM in /Clr
Toomy Ling
commctrl.h contains this typedef:
typedef struct _TREEITEM *HTREEITEM;
This is why you are seeing _TREEITEM in the diagnostic.
I'm just guessing: Make sure that something important isn't being exclude because there is a #define WIN32_LEAN_AND_MEAN in your source code. Wizard generated projects put this in stdafx.h.
Doyle J.
I have not tried fiddling with the Lean and Mean def's as it seems inconsistent to do so. If afxcmn.h is included then the typedef above should occur regardless.
The code uses #define VC_EXTRALEAN - it is quite diverse, but is mainly client side DBMS using ODBC with common controls.
Thanks...
- Tim
Glj12
control header files.
To fix the problem define the following in your stdafx.h
struct _TREEITEM
{};
More info:
HTREEITEM is defined as typedef struct _TREEITEM* HTREEITEM; for typesafety.
In native C++, not having struct _TREEITEM define is not a problem, but the CLR
needs an actual definition for a type even when just creating a pointer to it.
Ronald Laeremans
Visual C++ team
Don Mylrea
I'll try it tomorrow and get back.