Re: [perl-win32-gui-hackers] TreeView::GetParent and proper subclassing

[Robert M. <rob...@us...>]

On 26/06/07, Robert May <rob...@us...> wrote:
> On 22/06/07, Salvador Ortiz Garc=EDa <so...@ms...> wrote:
> > Hi all,
> >
> > This is my first post to the list, so forgive me if this was discussed
> > before.
>
> I don't think it has been discussed before,  but I have noticed it
> myself.  I didn't find it enough of an issue to want to deal with it.
>
> >
> > Reflecting the Win32 API, Win32::GUI::TreeView has a GetParent method t=
o
> > get the parent node (HTREEITEM) of a node, nothing related with the
> > GetParent common method of Win32::GUI.
> >
> > The common call
> >
> >   my $parentWin =3D $SomeControl->GetParent();
> >
> > simply don't work when $SomeContros isa TreeView, so right now when I
> > need the parent window of the TV control we must use an ugly workaround=
:
> >
> >   my $parentWin =3D Win32::GUI::GetParent($TreeView);
> >
> > The following patch cures that, properly subclassing the TreeView with
> > only minimal semantic changes IMHO:
> >
> > When called without NODE or with NODE equal zero (NULL, an invalid
> > HTREEITEM value anyway) now TreeView::GetParent() returns the parent
> > window, if any, or undef as Win32::GUI::GetParent() does.
> >
> > Any other value for NODE returns the handler of the parent NODE (or NUL=
L
> > at the root NODE) as documented.
> >
> > So the following works as spected:
> >
> >   sub TV_NodeClick {  # Click on a node, OEM form
> >     my($TreeView, $node) =3D @_;
> >     my $parentWin =3D $TreeView->GetParent();
> >     my $parentNode =3D $TreeView->GetParent($node);
> >     ...
> >
> > Comments?
>
> I'm a bit short of time at the moment, but I'd like to give this some
> more though, as one of the things I strive for is backwards
> compatibility and I'm not completely convinced.  I think the idea is
> OK, but I'd like to tinker with the implementation a little ... give
> me a couple of weeks to mull it over.
>
> Many thanks for the contribution.
>
> Regards,
> Rob.

OK, having thought about it I propose the following.  The only
significant change is how I determine the behaviour.  There is
probably code like this in the field:

  my $parent_node =3D $tv->GetParent($node);

where $node is calculated.  It would be surprising if when $node is 0
(or indeed undef) to get back a Win32::GUI::Window object.  So I check
the number of items actually passed, and only fallback to the
GetParent() window method if no arguments are passed:

  my $parent_window_object =3D $tv->GetParent();

Regards,
Rob.

I haven't actually compiled and tested this yet:

    #######################################################################=
####
    # (@)METHOD:GetParent(NODE)
    # Returns the handle of the parent node for the given B<NODE>.
    #
    # NOTE: With no B<NODE> parameter this is the standard
    # L<GetParent()|Win32::GUI::Reference::Methods/GetParent>
    # method, returning the parent window.
HTREEITEM
GetParent(handle,item =3D NULL)
    HWND handle
    HTREEITEM item
CODE:
    if(items =3D=3D 1) { /* NOTE this is the XS defined 'items' var, not 'i=
tem' */
        SV   *SvParent;
        HWND parentHandle =3D GetParent(handle);

        if (parentHandle && (SvParent =3D
SV_SELF_FROM_WINDOW(parentHandle)) && SvROK(SvParent)) {
            XPUSHs(SvParent);
            XSRETURN(1);
        }
        else {
            XSRETURN_UNDEF;
        }
    }
    else {
        RETVAL =3D TreeView_GetParent(handle, item);
    }
OUTPUT:
    RETVAL