One of the frustrating things in WPF is that objects in the Resources Collection can't see the DataContext from their containing control. It makes sense when you think about it as they are not within the Logical / Visual Tree, which Dependency Properties can inherit down. Whilst it doesn't normally affect me, today I came across a need to have this.
I've just worked on a view where we want to expose a collection in a next-previous way, and expose a 'CurrentItem' property. Whilst we could have done it in our ViewModel, in our scenario we don't want the ViewModels becoming aware of the next / prev, and just to be aware that they are given a list of items, and one of them is selected.
I went down the approach of a control which inherited from FrameworkElement as it had a DataContext then put it in the Resources Collection. Of course this didn't work as as we said at the beginning, stuff in the Resources cannot access the DataContext. BUT back up a minute... there is a control which seems able to do this - the CollectionViewSource. How does it do it? Heh heh, Reflector revealed the internal hack which MS used to somehow ram the inheritence of DP's into this unsuspecting class.
Nasty, but it just so happens we can exploit this for our own purposes. CollectionViewSource wraps a collection which it can obtain by binding to the DataContext, and it is not marked as sealed so we can extend it and add our own behaviour.
What I ended up doing was subclassing CollectionViewSource and adding a NextCommand, PreviousCommand, and SelectedItem dependency property to my subclass. (side note - we use a OneWayToSource binding to reverse the SelectedItem back onto the ViewModel we can bind to a standard .Net property on the ViewModel).
All sounds good, but there was one more issue. The CollectionViewSource is a bit of a liar, in that when you bind to it, you don't actually bind directly to it, but instead to the Collection it exposes. It makes for a nicer syntax in that 99% of times you use it, all you are interested in is that exposed collection. For us though we need to drill into our actual class to get at our subclasses properties. That's where that strange property on Binding, BindsDirectlyToSource comes in. It lets us probe past that outer facade of the class and get into the real object.
Our code is not far off being acceptable now. It looks something like:
<SummaryContentActionView> <!-- the scaffolding view which uses a template to define the layout -->
<SummaryContentActionView.Resources>
<NextPreviousCollection x:Key="col" Items="{Binding Contract.Items}" SelectedItem="{Binding SelectedItem, Mode=OneWayToSource}" />
</SummaryContentActionView.Resources>
<SummaryContentActionView.MainContent> <!-- object DP exposed from the scaffold contol -->
<StackPanel>
<Button Command="{Binding Source={StaticResource col}, Path=NextCommand, BindsDirectlyToSource=True}" />
</StackPanel>
</SummaryContentActionView.MainContent>
</SummaryContentActionView>
Tuesday, June 22, 2010
Subscribe to:
Post Comments (Atom)
1 comment:
That is nice information. I love this types of post.
Thanks a lot..
fostering agencies London
Post a Comment