tomsell has asked for the wisdom of the Perl Monks concerning the following question:

Contacting the Win32::GUI maintainer seems somewhat difficult, so would an XS hacker please set me straight? As this post also contains a, cough, "fix", others might find this useful.

Issue is this: the Win32::GUI TreeView->InsertItem() method works correctly on 32bit perl but does not on 64bit perl (this is Win32::GUI 1.12 under Strawberry 5.22.1 on Win7).

Run this code on both perl versions and compare the order of items in the tree (or run on x64 only and be baffled):

use strict; use Win32::GUI; sub TVI_FIRST { 0xFFFF0001 } my $Window = new Win32::GUI::Window( -name => "Window", -text => "Win32::GUI v. $Win32::GUI::VERSION TreeView: 32bit vs. + 64bit", -height => 200, -width => 350, -left => 100, -top => 100, ); my $TV = $Window->AddTreeView( -width => $Window->ScaleWidth, -height => $Window->ScaleHeight, -left => 0, -top => 0, -lines => 1, -rootlines => 1, -buttons => 1 ); my $rootNode = $TV->InsertItem( -text => "rootNode", ); my $childNode = $TV->InsertItem( -parent => $rootNode, -text => "childNode", -item => TVI_FIRST ); my $childAtt2 = $TV->InsertItem( -parent => $childNode, -text => "childAtt2", -item => TVI_FIRST ); my $childAtt1 = $TV->InsertItem( -parent => $childNode, -text => "childAtt1", -item => TVI_FIRST ); # root attribute inserted _after_ inserting child nodes, but should # display _before_ child nodes my $rootAtt1 = $TV->InsertItem( -parent => $rootNode, -text => "rootAtt1", -item => TVI_FIRST ); $TV->Expand($_) for($rootNode, $childNode); $Window->Show(); Win32::GUI::Dialog(); # eof

Since this is a bitness issue, my hunch is that it must be related to pointers. I think I tracked this down as far as GUI_Helpers.cpp::handle_From() where the conversion of integers to pointers for InsertItem() takes place.

I "fixed" the issue in the definiton of InsertItem() in TreeView.xs by replacing line 815

Insert.hInsertAfter = (HTREEITEM) handle_From(NOTXSCALL ST(next_i));

with

switch(SvIV(ST(next_i))){ case 0xFFFF0001: Insert.hInsertAfter = TVI_FIRST; break; case 0xFFFF0002: Insert.hInsertAfter = TVI_LAST; break; case 0xFFFF0003: Insert.hInsertAfter = TVI_SORT; break; default: Insert.hInsertAfter = (HTREEITEM) handle_From(NOTXSCALL ST(next_i) +); break; }

This looks pretty awful, even to me as a non-XS hacker.

So my question: what is the underlying problem and how is it fixed properly?

Replies are listed 'Best First'.
Re: x64 Win32::GUI TreeView broken, question and "fix" included
by coicles (Sexton) on Mar 17, 2016 at 01:12 UTC
    Changing TVI_FIRST fixes the problem for me with 64-bit (but I didn't try 32-bit yet!):
    sub TVI_FIRST () { -0x0FFFF }

    Here is its definition in CommCtrl.h:
    #define TVI_FIRST   ((HTREEITEM)(ULONG_PTR)-0x0FFFF)

      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.

        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.
Re: x64 Win32::GUI TreeView broken, question and "fix" included
by Anonymous Monk on Mar 17, 2016 at 01:33 UTC

      Using the same wrong constant as my sub returns wouldn't be any help. The problem is my inability to understand the macro definition in the C header file.

      Also, IMHO Constants.PL is nice to have, but to promote a fast startup especially for large GUI definitions, I'd recommend to define the set of required constants in the application script.

        Also, IMHO Constants.PL is nice to have, but to promote a fast startup especially for large GUI definitions, I'd recommend to define the set of required constants in the application script.

        Have you actually measured this? I think as an optimization , it isn't :)