I have a XAML view with a list box:
<control:ListBoxScroll ItemSource="{Binding Path=FooCollection}"
SelectedItem="{Binding SelectedFoo, Mode=TwoWay}"
ScrollSelectedItem="{Binding SelectedFoo}">
<!-- data templates, etc. -->
</control:ListBoxScroll>
The selected item is bound to a property in my view. When the user selects an item in the list box my SelectedFoo property in the view model gets updated. When I set the SelectedFoo property in my view model then the correct item is selected in the list box.
The problem is that if the SelectedFoo that is set in code is not currently visible I need to additionally call ScrollIntoView
on the list box. Since my ListBox is inside a view and my logic is inside my view model ... I couldn't find a convenient way to do it. So I extended ListBoxScroll:
class ListBoxScroll : ListBox
{
public static readonly DependencyProperty ScrollSelectedItemProperty = DependencyProperty.Register(
"ScrollSelectedItem",
typeof(object),
typeof(ListBoxScroll),
new FrameworkPropertyMetadata(
null,
FrameworkPropertyMetadataOptions.AffectsRender,
new PropertyChangedCallback(onScrollSelectedChanged)));
public object ScrollSelectedItem
{
get { return (object)GetValue(ScrollSelectedItemProperty); }
set { SetValue(ScrollSelectedItemProperty, value); }
}
private static void onScrollSelectedChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
var listbox = d as ListBoxScroll;
listbox.ScrollIntoView(e.NewValue);
}
}
It basically exposes a new dependency property ScrollSelectedItem
which I bind to the SelectedFoo
property on my view model. I then hook into the property changed callback of the dependent property and scroll the newly selected item into view.
Does anyone else know of an easier way to call functions on user controls on a XAML view that is backed by a view model? It's a bit of a run around to:
- create a dependent property
- add a callback to the property changed callback
- handle function invocation inside the static callback
It would be nice to put the logic right in the ScrollSelectedItem { set {
method but the dependency framework seems to sneak around and manages to work without actually calling it.
Have you tried using Behavior... Here is a ScrollInViewBehavior. I have used it for ListView and DataGrid..... I thinks it should work for ListBox......
You have to add a reference to
System.Windows.Interactivity
to useBehavior<T> class
Behavior
Usage
Add alias to
XAML
asxmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity"
then in your
Control
Now When ever "MyItem" property is set in
ViewModel
the List will be scrolled when changes are refelected.I took Ankesh's answer and made it not dependent on the blend sdk. The downside of my solution is that it will apply to all listboxes in your app. But the upside is no custom class needed.
When your app is initializing...
This makes all of your listboxes scroll to selected (which I like as a default behavior).
I know this is an old question, but my recent search for the same problem has brought me to this. I wanted to use the behavior approach, but didn't want a dependency on the Blend SDK just to give me
Behavior<T>
so here's my solution without it:and then usage is just
I'm using this (in my opinion) clear and easy solution
where
listView
is name ofListView
control in xaml,SelectedItem
is affected from my MVVM and code is inserted in constructor in xaml.cs file.After reviewing the answers a common theme came up: external classes listening to the SelectionChanged event of the ListBox. That made me realize that the dependant property approach was overkill and I could just have the sub-class listen to itself:
I feel this is the simplest solution that does what I want.
Honourable mention goes to adcool2007 for bringing up Behaviours. Here are a couple of articles for those interested:
http://blogs.msdn.com/b/johngossman/archive/2008/05/07/the-attached-behavior-pattern.aspx
http://www.codeproject.com/KB/WPF/AttachedBehaviors.aspx
I think for generic behaviours that will be added to several different user controls (e.g. click behaviours, drag behaviours, animation behaviours, etc.) then attached behaviours make a lot of sense. The reason I don't want to use them in this particular case is that the implementation of the behaviour (calling
ScrollIntoView
) isn't a generic action that can happen to any control other than a ListBox.Try this: