As a matter of fact, I am using WPF (sorry for not pointing that out). I didn’t realize there was a difference, so I didn’t bother checking if it worked, since I read it didn’t for silverlight. Thanks for point that out!

The only piece of the puzzle that’s missing now is the blend issue.

Kevin

I’m assuming you’re using Silverlight. If you were using WPF, you would be able to place the two CollectionViewSources in the resources section of your view, and they would inherit the data context as expected. In Silverlight this doesn’t happen though. The Silverlight workaround you point out in the link is good. It’s unfortunate that it can’t be done in XAML, but it’s really not that much extra code. At some point, I expect to see the WPF DataContext inheritance in Silverlight too.

Sorry I can’t help you with the Blend question.

Bea

I thought this might work for the scenario I’m using:

Suppose I have one ObservableCollection. I want to show the items of this collection in two different locations, each with a different sorting. The way to go, I presume, would be to create a CollectionViewSource in each of the two different locations, with different sorting specified in xaml.

However, two problems arise:

1) As featured here http://msdn.microsoft.com/en-us/library/system.windows.data.collectionviewsource.aspx , the CollectionViewSource is defined in the resources section and its source is set to a locally defined resource/observableCollection. However, what if I’m working with MVVM? I would then like to bind the Source property of the CollectionViewSource to an ObservableCollection in my view model, which apparently can’t be done, since the CollectionViewSource has no access to the datacontext of the window/control it’s defined in (whose datacontext would be the view model). A possible solution would be this: http://www.silverlightplayground.org/post/2009/07/18/Use-CollectionViewSource-effectively-in-MVVM-applications.aspx The CollectionViewSource gets created in the view model and sorting gets applied there. You would then bind your itemscontrol.itemssource to the CollectionViewSource.View in the view model. However, you would lose the advantage of doing it all in XAML.
2) How is this all supposed to work in Blend? Ideally I would like the programmer to be able to write a viewmodel, which the user interface maker could use in Blend. However, when I’ve created the CollectionViewSource in the view model (as in the above scenario), it looks like Blend can’t resolve the object type when setting the ItemsSource of an ItemsControl to the view model’s CollectionViewSource.View. Which is understandable, since the CollectionViewSource.view isn’t typed.

Any ideas on this?

Bea

Your blog is amazing and very very usefull!
Keep shining! :-)

public class CollectionViewConverter : IValueConverter, INotifyPropertyChanged
{
private string _filterText = string.Empty;

public string FilterText
{
get
{
return _filterText;
}
set
{
_filterText = value;
foreach (CollectionViewSource cvs in _sources.Values)
{
cvs.View.Refresh();
}
PropertyChangedEventHandler localHandler = PropertyChanged;
if (localHandler != null)
{
localHandler(this, new PropertyChangedEventArgs(“FilterText”));
}
}
}

private void OnFilter(object sender, FilterEventArgs e)
{
e.Accepted = (e.Item as IOutput).Name.Contains(FilterText) || !_sources[e.Item].View.IsEmpty;
}

#region INotifyPropertyChanged Members

public event PropertyChangedEventHandler PropertyChanged;

#endregion

#region IValueConverter Members

private Dictionary _sources = new Dictionary();

public object Convert(object value, System.Type targetType, object parameter, System.Globalization.CultureInfo culture)
{
if (!_sources.ContainsKey(value))
{
CollectionViewSource childrenCvs = new CollectionViewSource();
childrenCvs.Source = value;
childrenCvs.Filter += OnFilter;
_sources.Add(value, childrenCvs);
}
return _sources[value].View;
}

public object ConvertBack(object value, System.Type targetType, object parameter, System.Globalization.CultureInfo culture)
{
throw new NotSupportedException();
}

#endregion
}

If you need top-level filtering as well you’ll need to hook up an identical filter method at that level (I have that sitting in the MainWIndow and use
e.Accepted = (e.Item as IOutput).Name.Contains(_filterBox.Text) || !((_treeView.ItemContainerGenerator.ContainerFromItem(e.Item) as Telerik.Windows.Controls.ItemsControl).ItemsSource as ICollectionView).IsEmpty;

For some reason I’d never considered using DataTemplate resources (as per option 2) although now you explain it I can understand why that doesn’t work (and I’ll remember that point for future).

Using a converter in the ItemsSource binding seems like a good idea and one that will work for me I think – The sample project is a great help, thank you.

I’d been using Linq up to now to populate a secondary collection, which works but feel like a rather heavy solution.

Anyway, thanks again for taking the time to reply in such detail. It has really helped fill in the gaps for me.

Best regards

John

WPF doesn’t have good intuitive support for filtering at different levels of the hierarchy, unfortunately. This scenario was discussed a few times when I was still on the team, but we never ended up adding better support for it.

To filter at different levels, you need to have a filter method for each of those levels. All collections of a level need to have that filter specified in their view. At first sight it seems like this would be easy to achieve through XAML, by adding a CollectionViewSource with a Filter to each HierarchicalDataTemplate, but it’s not as easy as it seems. I have seen people try three approaches to this problem, all of which don’t work. (Excuse me for any typos in the code/XAML below, as I’m just typing it on the fly, not compiling it.)

1. Add the CollectionViewSources for all levels to the window’s resources, and bind the ItemsSource of each HierarchicalDataTemplate to the corresponding CollectionViewSource:

(This assume the DataContext for the window is an ObservableCollection of Mountain.)

<Window.Resources>
<CollectionViewSource x:Key=”MountainsCVS” Source=”{Binding}” Filter=”FilterMountain” />
<CollectionViewSource x:Key=”LiftsCVS” Source=”{Binding Lifts}” Filter=”FilterLift” />
<CollectionViewSource x:Key=”RunsCVS” Source=”{Binding Runs}” Filter=”FilterRun” />

<HierarchicalDataTemplate DataType=”{x:Type local:Mountain}” ItemsSource=”{Binding Source={StaticResource FilterLift}}”>
<TextBlock Text=”{Binding Name}” />
</HierarchicalDataTemplate>

<HierarchicalDataTemplate DataType=”{x:Type local:Lift}” ItemsSource=”{Binding Source={StaticResource FilterRuns}}”>
<TextBlock Text=”{Binding Name}” />
</HierarchicalDataTemplate>
</Window.Resources>

This doesn’t work because all CollectionViewSources have the same data context – the collection of Mountain. Their data context doesn’t change depending on where they’re used.

2. Add the CollectionViewSource to the resources of the HierarchicalDataTemplate:

<HierarchicalDataTemplate DataType=”{x:Type local:Mountain}”>
<HierarchicalDataTemplate.Resources>
<CollectionViewSource x:Key=”LiftsCVS” Source=”{Binding Lifts}” Filter=”FilterLift” />
</HierarchicalDataTemplate.Resources>
<HierarchicalDataTemplate.ItemsSource>
<Binding Source=”{StaticResource LiftsCVS}” />
</HierarchicalDataTemplate.ItemsSource>
<TextBlock Text=”{Binding Name}” />
</HierarchicalDataTemplate>

The data context for the template is a specific Mountain instance, which leads people to believe that the CollectionViewSource would pick up the rigth data context. However, this doesn’t work because, although the each instance of the HierarchicalDataTemplate has its data context set to a specific Mountain, the resources section does not inherit that data context (it has no data context). This happens because the resources added there are shared across all instantiations of the template. So this solution doesn’t work either.

3. Add the CollectionViewSource directly in the ItemsSource of the HierarchicalDataTemplate:

<HierarchicalDataTemplate DataType=”{x:Type local:Mountain}”>
<HierarchicalDataTemplate.ItemsSource>
<Binding>
<Binding.Source>
<CollectionViewSource Source=”{Binding Lifts}” Filter=”FilterLift” />
</Binding.Source>
</Binding>
</HierarchicalDataTemplate.ItemsSource>
<TextBlock Text=”{Binding Name}” />
</HierarchicalDataTemplate>

In this case you end up with a nested binding, which also doesn’t pick up the data context as may be expected.

So, what can you do instead?

If your data doesn’t change, you can use a converter to filter the data at first load. You can take a look at a simple project that uses a converter for this purpose. The concept is quite simple – the converter gets added in the ItemsSource Binding, and the filter logic goes in the converter implementation.

<HierarchicalDataTemplate DataType=”{x:Type local:Lift}” ItemsSource=”{Binding Path=Runs, Converter={StaticResource FilterRunsConverter}}”>
<TextBlock Text=”{Binding Name}” />
</HierarchicalDataTemplate>

If your data changes, you can write code that ensures that all TreeViewItems are data bound to views that wrap their original collections with the Filter property set. You may also consider adding filtering on the data logic side of the app, instead of using the client-side built-in filtering capabilities of WPF.

In addition, there may be other creative and tricky ways of adding CollectionViewSources with the Filter method directly in XAML, and if you find an elegant way of doing it, please let me know.

Hope this helps.
Bea