FindAscendantOrTop Visual Tree helper?

[michael-hawker]

We have FindAscendant and FindAscendantOrSelf, wondering if we need a FindAscendantOrTop which will return the top-most element that matches even if it fails to find in the exhaustive search at the top...?

Scenario: CommunityToolkit/Labs-Windows#278 - for Adorners, I want to basically walk the way to the top of the app, but if I don't find something, I still want the top-most 'root' element of the tree instead of null (as the current behavior would be).

@Sergio0694 thoughts?

[Sergio0694]

Mmh yeah that seems reasonable, though I wonder if it's not too niche 🤔

In the meantime, would this work?

element.FindAscendant<DependencyObject>(obj => obj is <WHATEVER> || VisualTreeHelper.GetParent(obj) is null);

As for the name if we did add this, maybe FindAscendantOrRoot would be better?

[michael-hawker]

Well I was thinking the type match may still matter (like the top-most ScrollViewer) so it may not be the Root of the app in all cases (just in my current scenario).

Trying to reduce repeat calls to VisualTreeHelper.GetParent at the moment, so I'm caching the last value in the predicate... 🙈

        FrameworkElement? lastElement = null;
        
        var adornerLayerOrTopMostElement = adornedElement.FindAscendant<FrameworkElement>((element) =>
        {
            lastElement = element;
            if (element is AdornerLayer)
            {
                return true;
            }

            return false;
        }) ?? lastElement;

[michael-hawker]

Ah, I also noticed @Sergio0694 we didn't implement the breadth/depth first search option for the logical helpers, only the visual ones.

I'm also realizing I want the depth restriction for adorners as well... like walk up to a ScrollViewer and then look down at most two levels for an AdornerLayer (contained within a Grid for instance as the content of the ScrollViewer).

I know these are technically new features for a patch release, but we've already got them in main for 7.1.3, so wondering if we want to make these improvements now? (Or should we revert the imporvement PR to re-introduce after more uniformly?) Thoughts?

FYI @Arlodotexe

[michael-hawker]

Tinkering with this on Adorners stream, thinking we need to enumerate all these different API signatures and probably split their implementations out in separate partial files, these things are getting huge (but they're so useful...)