Re^2: x64 Win32::GUI TreeView broken, question and "fix" included

Nice! Using the TVI_* values defined in commctrl.h instead of the ones documented in Win32::GUI works, both for x64 and x86.

Not that I'm any the wiser why it does. I had looked up the macro but was intimidated by the ULONG_PTR part (is that a cast?). I can also make no sense of the HTREEITEM macro but tend to think that it is not the same as a HWND used by handle_From() which screws up the advertised 0xFFFF000* values.

Comment on Re^2: x64 Win32::GUI TreeView broken, question and "fix" included

Replies are listed 'Best First'.
Re^3: x64 Win32::GUI TreeView broken, question and "fix" included by coicles (Sexton) on Mar 17, 2016 at 19:25 UTC
Yeah, the negative inte value gets cast to a ULONG_PTR, which is an unsigned integral type whose size is big enough to hold a pointer value -- an unsigned long in x86 builds and an unsigned __int64 (equivalent to unsigned long long) with x64. So with this cast, on x64, the negative int value is sign-extended and all upper bits in the ULONG_PTR end up being set to 1. HTREEITEM is actually a typedef of a pointer to a unique dummy struct type, so it is the same size as ULONG_PTR.	[reply]

Replies are listed 'Best First'.

Re^3: x64 Win32::GUI TreeView broken, question and "fix" included
by coicles (Sexton) on Mar 17, 2016 at 19:25 UTC

Yeah, the negative inte value gets cast to a ULONG_PTR, which is an unsigned integral type whose size is big enough to hold a pointer value -- an unsigned long in x86 builds and an unsigned __int64 (equivalent to unsigned long long) with x64. So with this cast, on x64, the negative int value is sign-extended and all upper bits in the ULONG_PTR end up being set to 1. HTREEITEM is actually a typedef of a pointer to a unique dummy struct type, so it is the same size as ULONG_PTR.

[reply]