views:

79

answers:

1

I have some code that looks like this:

<Expander Header="{Binding SelectedSlot.Name}"
          Visibility="{Binding ShowGroupSlot, Converter={StaticResource BooleanToVisibility}}">
    <Controls:GroupPrototypeSlotControl Slot="{Binding DataContext.SelectedSlot, 
        RelativeSource={RelativeSource Mode=FindAncestor,  AncestorType={x:Type Expander}}}" />
</Expander>

This works, but the ugliness of the Slot Binding bothers me. This is required because the GroupPrototypeSlotControl has a GroupPrototypeViewModel as its DataContext. If I simply use {Binding SelectedSlot}, it attempts to resolve it on the 'child' ViewModel, which fails. I get around this by explicitly looking at the DataContext of my parent control. Is there a cleaner way to do this type of binding?


EDIT: I found a cleaner way of resolving my problem, though it still feels like a hack. I modified the GroupPrototypeSlotControl so that it has a top-level LayoutRoot (a StackPanel, in this case) and then set the DataContext of LayoutRoot to the ViewModel rather than setting the DataContext of the entire control. This allows me to use the {Binding SelectedSlot} syntax where I use the control (since the control still has the parent DataContext), at the cost of slightly increasing the complexity of the control. In general, this is probably the better pattern for a custom control, since the consumer of the control expects a {Binding} to resolve to their parent DataContext if one isn't explicitly specified.

+1  A: 

A slightly cleaner (shorter) way is to use ElementName in your Binding like this:

<Expander Header="{Binding SelectedSlot.Name}"
          x:Name="expander"
          Visibility="{Binding ShowGroupSlot, Converter={StaticResource BooleanToVisibility}}">
    <Controls:GroupPrototypeSlotControl Slot="{Binding DataContext.SelectedSlot, ElementName=expander}" />
</Expander>
wpfwannabe