Silverlight XAML Attribute Definition Order Matters

Question

I was working with the ComboBox control and couldn't get the SelectedItem to be set from the property on my viewmodel. Here is the control definition:

<ComboBox x:Name="jobEmployee" Grid.Column="1" Grid.Row="2" 
    Margin="4" HorizontalAlignment="Left" Width="150"
    SelectedItem="{Binding Path=EditingJob.Employee, Mode=TwoWay, ValidatesOnExceptions=true, NotifyOnValidationError=true}"
    ItemsSource="{Binding Path=Employees, Mode=OneWay}"
    DisplayMemberPath="FullName"/>

I had another Combobox control that worked jut fine. The difference between one that would set the SelectedItem and the one that wouldn't was the order of the attribute definition. Here is the working control definition:

<ComboBox x:Name="jobEmployee" Grid.Column="1" Grid.Row="2" 
    Margin="4" HorizontalAlignment="Left" Width="150"
    ItemsSource="{Binding Path=Employees, Mode=OneWay}"
    SelectedItem="{Binding Path=EditingJob.Employee, Mode=TwoWay, ValidatesOnExceptions=true, NotifyOnValidationError=true}"
    DisplayMemberPath="FullName"/>

The difference between the 2 is that the ItemsSource is defined before the SelectedItem on the working one which leads me to believe that in this case at least, the attribute definition order matters. Am I missing something or have others found this to be true? Has it been documented anywhere?

Answer 1

Yes order can matter. Consider that XAML reading involves the creation of objects and the assignment of values to the properties of these objects. Its not possible to assign property values at the same time, clearly one property is going to be assigned followed by another and then another until all properties are assigned.

Since assigning properties in some objects results in side-effects and other code running the order of assigning those properties can impact the result. This of course is a bad thing.

Answer 2

The next time you have a problem similar to this and you suspect the binding might be failing because of the order. Check your output window, it displays all binding errors, So from that error you could have deduced that the ItemSource was null at time of binding the SelectedItem property

Answer 3

In any circumstance in which the order that properties are set is important, you should use element syntax, not attribute syntax, to represent those properties in your XAML:

<ComboBox x:Name="jobEmployee" Grid.Column="1" Grid.Row="2" 
   Margin="4" HorizontalAlignment="Left" Width="150" DisplayMemberPath="FullName">
   <ComboBox.ItemsSource>
      <Binding Path="Employees" Mode="OneWay"/>
   <ComboBox.ItemsSource>
   <ComboBox.SelectedItem>
      <Binding Path="EditingJob.Employee" Mode="TwoWay" 
         ValidatesOnExceptions="true" NotifyOnValidationError="true"/>
   </ComboBox.SelectedItem>
</ComboBox>

According to the XML recommendation, the ordering of attributes on an element is not significant. XML tools aren't required to retain the order they appear in. So if, for instance, you processed this ComboBox element with an XSLT transform (not a crazy idea in some circumstances), the transform might change the ordering of your attributes, even if it's doing <xsl:copy-of>. The XSLT processor probably won't do this, but it's not required not to.

What effect would randomizing the order of the attributes on every element in your XAML do to the behavior of your application? The answer to that question ought to be "nothing."

This is an aspect of XAML that makes me very nervous.