Re: Re[2]: wxTreeCtrl::EnsureVisible expands only one item

Thanks Vadim.

I can reproduce the problem in the TreeCtrl sample, by replacing the 
function MyFrame::OnEnsureVisible() with this:

/// BEGIN CODE

static void MarkMatchingItems(wxTreeCtrl* tree, const wxTreeItemId& id, 
wxString searchText)
{
    wxString itemText = tree->GetItemText(id).MakeLower();

    bool bMatch = false;
    if (searchText.IsEmpty())
    {
        // If empty, match nothing.
    }
    else
    {
        tree->Collapse(id);
        bMatch = itemText.Find(searchText) != wxNOT_FOUND;
    }

    //tree->SetItemBold(id, bMatch);
#ifdef macintosh
    tree->SetItemTextColour(id, bMatch ? *wxBLACK : 
tree->GetForegroundColour()); // *wxWHITE
#endif
    tree->SetItemBackgroundColour(id, bMatch ? *wxCYAN : 
tree->GetBackgroundColour()); // *wxWHITE
    if (bMatch)
    {
        tree->EnsureVisible(id);
        //tree->ScrollTo(id);
    }

    wxTreeItemIdValue cookie;
    wxTreeItemId child = tree->GetFirstChild(id, cookie);
    while (child.IsOk())
    {
        MarkMatchingItems(tree, child, searchText);
        child = tree->GetNextSibling(child); // tree->GetNextChild(child, 
cookie);
    }
}

void MyFrame::OnEnsureVisible(wxCommandEvent& WXUNUSED(event))
{
    //const wxTreeItemId
    //    idLast = m_treeCtrl->GetLastTreeITem();
    //if ( idLast.IsOk() )
    //    m_treeCtrl->EnsureVisible(idLast);
    //else
    //    wxLogMessage("No last item");

    m_treeCtrl->Freeze();
    MarkMatchingItems(m_treeCtrl, m_treeCtrl->GetRootItem(), "3");
    m_treeCtrl->Thaw();
}

/// END CODE

With this change, when you select the "Make the last item visible" menu 
item, it does mark all the items with a "3" in their text in Cyan, but only 
the last couple nodes are visible.  The rest are hidden by collapsed parent 
nodes.

In wxWidgets 3.1, all the nodes that are marked in Cyan are also visible, 
with their parents expanded.

A couple notes about this:

One, if the calls to m_treeCtrl->Freeze() and m_treeCtrl->Thaw() are 
removed, then all the marked nodes are visible.  However, in our app, there 
are many hundreds of nodes, and without the Freeze call, the tree lags and 
flickers a lot when doing a search, so removing that from our app is not a 
good option.  This suggests that something about how things are handled 
while the control is frozen has changed, and this is likely a side effect 
of that.  I suspect that it has to do with the behavior of 
wxTreeCtrl::Collapse() while frozen.

Two, if I replace the call to tree->EnsureVisible(id) 
with tree->ScrollTo(id), it works correctly on Windows and shows all the 
marked nodes.  However, on Mac, the call to ScrollTo() seems to do nothing 
at all.

So, I have a workaround for now, which is to #ifdef the code to call 
ScrollTo() on Windows and EnsureVisible() on Mac.  That said, it would be 
good to get to the bottom of this so that the Windows code works the same 
as in 3.1.

Thanks,
Dan


On Thursday, June 12, 2025 at 7:02:50 PM UTC-5 Vadim Zeitlin wrote:

> On Thu, 12 Jun 2025 16:51:50 -0700 (PDT) Dan Korn wrote:
>
> DK> I do indeed see a difference in behavior between wxWidgets 3.1 and 3.2,
> DK> on the same Windows machine. Specifically, between versions 3.1.2 and
> DK> 3.2.4. I'm on Windows 10 Pro, but the same issue occurs on Windows 11
> DK> with wxWidgets 3.2.
>
> OK, thanks, so we can't blame Microsoft this time. Well, it was worth a
> try...
>
> DK> I also see the call to TreeView_EnsureVisible (the macro equivalent of
> DK> TVM_ENSUREVISIBLE) in wxTreeCtrl::EnsureVisible() in
> DK> src/msw/treectrl.cpp. And that does seem to have been unchanged for
> DK> quite some time. Nevertheless, there is this difference in behavior
> DK> when it's called multiple times.
>
> So you can't reproduce this in the treectrl sample? It has menu item for
> making the last item visible and if the problem could be reproduced there,
> it would make it much simpler for me to debug it. Of course, if it can't,
> but you can provide a simple patch to the sample allowing to do it, please
> do it and please open an issue on GitHub and attach this patch to it.
>
> DK> Do you have any idea how to find the relevant code change and work
> DK> around it?
>
> The brute force solution would be to run git-bisect between 3.1.2 and
> 3.2.4. There are ~8000 commits there, but this is still just 13 iterations,
> so bisect shouldn't be too onerous to do. And finding the commit which
> broke it should give at least some idea of what the problem is.
>
> DK> We do need other changes in wxWidgets 3.2, so rolling back completely
> DK> is not a good solution.
>
> BTW, have you tried 3.3.0? I don't see any changes that could affect this,
> but if it works there, upgrading directly to it could be a solution.
>
> Otherwise, I'd really need some way of reproducing the problem to be able
> to do anything about it.
>
> Good luck,
> VZ
>
> -- 
> TT-Solutions: wxWidgets consultancy and technical support
> https://www.tt-solutions.com/
>

-- 
Please read https://www.wxwidgets.org/support/mlhowto.htm before posting.
--- 
You received this message because you are subscribed to the Google Groups "wx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/wx-users/0af6edeb-53a6-49ac-aa6a-75156156fc83n%40googlegroups.com.