4

Lately I've seen some comments about walking the visual tree being bad practice (here for instance), but I haven't seen or found a reason for why this would be bad practice.

In a project I'm working on there's quite a bit of tree walking, so I'm wondering if I should bother changing all this to something else or just let it be as it is.

So, I guess my main question here is if visual tree walking really is bad practice, and more importantly, if it is, why?

Also, where (if at all?) would it be ok to walk the visual tree?

Community
  • 1
  • 1
Eirik
  • 4,135
  • 27
  • 29

3 Answers3

1

  1. Walking a visual tree often amounts to breaking into the abstraction provided by WPF "natural" mechanisms, enforcing manually what the framework should be doing by itself (via XAML declarations, databinding etc.). It's a hack, simply put. Sometimes it indicates that one wasn't sure how to use WPF properly. (Which is difficult to use indeed, by the way).

  2. You can't really know at all times whether the visual tree is complete or not; WPF may not have generated all the controls yet (for example, while populating a list with many items). In order to solve this, you need to implement safeguards, handle LayoutUpdated events etc., which makes your code overly complex.

Konrad Morawski
  • 8,307
  • 7
  • 53
  • 91
1

I would say firstly that you're going to get a variety of opinions on this subject.

In the example you linked to, I'd say a visual tree walker in that case was the wrong solution - WPF is usually best used with some sort of MVVM or MVP-like pattern, and that means data binding, and if you bind to appropriate structures you can eliminate a lot of what you might have done with visual tree walking.

I only tend to use it for 'special effects', as it were. The big internal WPF app I work on has some visual tree walking code which adds some convenient behaviour to a few ItemControls in a reusable manner (lots of fun with type parameters to make that one work).

We also walk the visual tree in the implementation of some attached properties which are part of the system that controls whether a particular user is allowed to manipulate certain parts of the UI. This is because this system has to transform the visual tree regardless of what the underlying data says - user permissions are a cross-cutting concern which the underlying data shouldn't have to worry about at every single step.

Basically we only do it to do things to the UI itself - UI behaviour that can't be done in a more convenient way (and let's be honest, most other ways are more convenient in most cases), or actually adjusting the visual tree based on some factor which isn't conveniently expressible in the data the UI's bound to. If it's about manipulating data, we always do it in the backend data structures or ViewModels.

Matthew Walton
  • 9,809
  • 3
  • 27
  • 36
0

It depends why you are walking visual tree. There is a lot of mechanisms that automate your view and for most cases they are more then enough to do even very complex controls.

In my years of work with wpf I have used visual tree walking only when creating some non standard behaviors that couldn't be done otherwise (or I did not find other way to do them). I consider walking visual tree a tool like any other for instance reflection. It is good to know it and it has its applications and drawbacks.

Rafal
  • 12,391
  • 32
  • 54