0

I’ve been having issues with the TreeView in WPF. This control makes it very hard to access the TreeViewItems it’s showing.

On several occasions I have worked around the need to access a TreeViewItem, for example I’ve accepted the fact that I’m not supposed to access a node’s parent via TreeView (and am supposed to instead keep track of the parent myself). I’ve been doing this for two reasons: first, it’s obviously extremely hard to get at the TreeViewItems, and secondly, I’ve been told that it’s hard because I’m not supposed to need them if I do things right.

However, this time I really see no way around this.

Basically, all I want is, given one of my viewmodel instances, scroll the tree view to it. This is trivial if I could just get the corresponding TreeViewItem.

Am I doing things wrong again by trying to get at the TreeViewItem, or would that be the right approach?

Community
  • 1
  • 1
Roman Starkov
  • 59,298
  • 38
  • 251
  • 324
  • 1
    [Here](http://www.codeproject.com/Articles/28959/Introduction-to-Attached-Behaviors-in-WPF) is an artical by Josh Smith that deals with exactly what you want - scrolling treeview items into view. Josh's solution uses attached behaviours. – GazTheDestroyer Mar 23 '12 at 10:37

4 Answers4

4

Take a look at Simplifying the WPF TreeView by Using the ViewModel Pattern article by Josh Smith. I hope it helps.

Jalal
  • 6,594
  • 9
  • 63
  • 100
  • This article is very good but doesn't explain how to use the SelectedItem or IsSelected property. – Rachael Mar 12 '13 at 16:56
1

Admittedly this is not straightforward but you can probably still do this while keeping a separation which does not require you to access the TreeViewItems knowingly. The essence in WPF is binding as already noted by Kent Boogaart in your other question, here however you need to somehow deal with events. Your view-model needs to fire a BringIntoView event of its own while the view needs to react.

The easiest method might be to add a EventSetter on Loaded to make the TreeViewItems subscribe to said event on their DataContext which should be your view-model (if it isn't you can wait for DataContextChanged).

Community
  • 1
  • 1
H.B.
  • 166,899
  • 29
  • 327
  • 400
  • Sounds like this might be what I need. Thank you. – Roman Starkov Mar 23 '12 at 11:03
  • It’s real hard to accept the fact that the WPF approach is to re-expose manually in every view-model everything that’s already exposed by `TreeViewItem`. I get the idea though. – Roman Starkov Mar 24 '12 at 10:45
  • @romkyns: You will get used to it, also the mapping is not necessarily 1:1, as in theory you could have different views, e.g. if you represent one node's children in a simple ListBox, the event would be the same but it would affect another control. Reexposing just what you need gives you more flexibility and decouples the state from the current view. – H.B. Mar 24 '12 at 13:07
0

No, I dont see in what way accessing the items of a treeview is wrong.

I think the difficulties you are encountering are because you aren't seeing the treeview as it should be.

A leaf has a parent, but no children. A node can have a parent, and can have children. A node without a parent is a root.

Based on these principles (SourceMaking Composite pattern) you should be able to do whatever you want using recursivity. (in both XAML and code)

squelos
  • 1,189
  • 6
  • 16
  • The difficulty I am encountering is not in the understanding of trees; it’s in the API. The difficulty is **how**, given an item from my bound collection, can I get the corresponding `TreeViewItem`. – Roman Starkov Mar 23 '12 at 10:17
0

I’ve come to the conclusion that it can’t be altogether wrong. The first piece of evidence comes from Bea Stollnitz’s post about ListView: if one of the WPF developers explains how this might be done, it can’t be that wrong.

The other piece of evidence comes from this highly-voted question/answer: MVVM madness. MVVM undoubtedly has its benefits, but sometimes the cost of following MVVM is so high that it’s just silly following through with it, especially in a small one-man application. Do you really want to expose IsSelected and IsExpanded the way you’re supposed to?

As a result, I felt justified to try and figure out how to expose the TreeViewItem corresponding to an item with less effort from the developer, under the assumption that they will never need the more advanced features that resulted in TreeViewItems being this hard to access (like displaying the same ViewModels in multiple different controls... how often have you needed that!...)

I posted the result of this effort as an answer on another question.

Community
  • 1
  • 1
Roman Starkov
  • 59,298
  • 38
  • 251
  • 324