Suggestion to change default method behavior for .Children (and add it to all elements)

[grubioe]

Copying from WPF Samples Repo: microsoft/WPF-Samples#77

Dear Devs,
it is kind of a pain to iterate through the whole page xaml for finding certain items.
The default methods .Content and .Children differ on the tree which is annoying (for beginners).
Could you improve the default method like using default examples for VisualTreeHelper?

Further it is annoying being forced to cast the method
(having not the same container providing .Children method) for the IntelliCode support.

Using multiple or deep Pages could be written recursively or iteratively much faster when the type is fixed providing and the same method could be used.

This
https://stackoverflow.com/questions/636383/how-can-i-find-wpf-controls-by-name-or-type/1759923#1759923
and this
https://codereview.stackexchange.com/questions/44760/is-there-a-better-way-to-get-a-child
relates to that.

[weltkante]

Not sure what exactly is asked here.

(a) Having a Children property on all controls is not great. There are many controls which treat their children as an implementation detail and do not want to expose them to callers.

Besides, there are multiple trees (at least visual and logical, some controls have additional ones) - exposing one of them as property on all controls will pose the question which to expose. The existing Children properties are implementation details of their containers, i.e. each container decides what to expose as "children" - the container does not necessarily have to place his "children" immediately into the visual tree as his own children, he could group them into intermediate layout containers or look up containers in the control template to put the children in.

(b) Recursively traversing children down the tree is an antipattern in WPF, it should not be encouraged by the framework

• it is expensive (you are searching the whole subtree, including recursively expanded templates)
• since WPF has lazy layout you often require an expensive UpdateLayout call to ensure the visual tree is up to date when you search it
• children from multiple or nested containers are not easily separated
• virtualizing controls cannot be handled consistently (they may either remove cached children from the visual tree or turn them invisible, depending on the implementation)
• by searching down the visual tree you are implicitely depending on the implementation (including xaml templates) of every single control down the visual tree - this makes very fragile code which easily breaks if any of the implementations or templates change

The correct way to locate child elements is using their names. If you have XAML code behind you can access elements directly by name already, if you are using templates there are existing functions to find named elements, and there are existing contracts (TemplatePartAttribute) which named elements calling code can expect in a template. Any elements beyond that contract are not guaranteed to be part of the style, though if you just defined the name in your own style then you can of course rely on it being present.

[vatsan-madhavan]

I'm reluctant to go down the path of considering .Children etc. that serves mainly to expose calls to VisualTreeHelper API's.

If there is a specific and scoped addition to VisualTreeHelper that is being suggested, we can consider it.

There are always going to be individual use-cases that fail to be addressing directly by existing VisualTreeHelper API's - our goal is not to provide every conceivable functionality directly in there. The idea is to address the common use-cases and allow developers to roll their own helper methods for the uncommon use-cases.

We'd want to be persuaded that a common use-case is being addressed as part of any proposal for additions to VisualTreeHelper.

/cc @matu3ba (who opened the original issue on Microsoft/WPF-Samples)

[ghost]

This issue has been automatically marked as stale because it has marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. Thank you for your contributions!