66
votes

According to the x:Reference Markup Extension page on MSDN, x:Reference

References an instance that is declared elsewhere in XAML markup. The reference refers to an element's x:Name.

According to the Binding.ElementName Property page on MSDN, ElementName

The value of the Name property or x:Name Directive of the element of interest.

Looking back at the remarks section on the first page:

x:Reference and WPF

In WPF and XAML 2006, element references are addressed by the framework-level feature of ElementName binding. For most WPF applications and scenarios, ElementName binding should still be used. Exceptions to this general guidance might include cases where there are data context or other scoping considerations that make data binding impractical and where markup compilation is not involved.

For completeness, here is part of the remarks section on the ElementName page:

This property is useful when you want to bind to the property of another element in your application. For example, if you want to use a Slider to control the height of another control in your application, or if you want to bind the Content of your control to the SelectedValue property of your ListBox control.

Now, while I am fully aware of when and how to use the ElementName property, I don't fully understand the difference between it and the x:Reference markup extension. Can anybody please explain this and in particular, expand on the last sentence shown from the x:Reference remarks section?:

Exceptions to this general guidance might include cases where there are data context or other scoping considerations that make data binding impractical and where markup compilation is not involved.

2

2 Answers

73
votes

Basically like you said those two do almost the same. However there are small differences under the hood.

{x:Reference ...} -> returns just a reference of an object it doesn't create that "bridge" between two properties like binding would do. Behind all that a service is being used that searches for the given name in a specific scope which is usually the window itself.

{Binding ElementName="..." } -> first of all it creates that binding object then it searches for the object name but not by using the same technique under the hood as x:Reference. The search algorithm moves up and/or down in VisualTree to find the desired element. Therefore a functional VisualTree is always needed. As example when used inside a Non-UiElement, it won't work. In the end the Binding stays and does its daily bread.

This won't work:

<StackPanel>
 <Button x:name="bttn1" Visibility="Hidden">Click me</Button>
 <DataGrid>
  <DataGrid.Columns>
    <DataGridTextColumn Visibility="{Binding ElementName=bttn1, Path=DataContext.Visibility}"/>
 ....

This works:

<StackPanel>
 <Button x:name="bttn1" Visibility="Hidden">Click me</Button>
 <DataGrid>
  <DataGrid.Columns>
    <DataGridTextColumn Visibility="{Binding Source={x:Reference bttn1}, Path=DataContext.Visibility}"/>
 ....

Sort of like that :)

3
votes

ElementName is platform specific. I.e. it may or may not be present based on which platform you're using. x:Reference elevates that concept to a XAML native feature. Thus any platform that supports XAML supports x:Reference.