Определение атрибута Silverlight XAML

Я работал с элементом управления ComboBox и не мог получить значение SelectedItem из свойства на моей модели viewmodel. Вот определение управления:

<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"/>

У меня был еще один элемент управления Combobox, который отлично работал. Разница между тем, который установил бы SelectedItem и тот, который не был бы порядком определения атрибута. Вот определение рабочего контроля:

<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"/>

Разница между 2 заключается в том, что ItemsSource определен до SelectedItem на рабочем, что заставляет меня полагать, что в этом случае, по крайней мере, порядок определения атрибута имеет значение. Я что-то упускаю или другие считают, что это правда? Документировано ли оно где-нибудь?

Ответ 1

Да, порядок может иметь значение. Считайте, что чтение XAML включает в себя создание объектов и присвоение значений свойствам этих объектов. Невозможно одновременно присвоить значения свойств, очевидно, что одно свойство будет назначено другому, а затем другому, пока не будут назначены все свойства.

Так как назначение свойств в некоторых объектах приводит к побочным эффектам, а другой код, выполняющий порядок назначения этих свойств, может повлиять на результат. Это, конечно, плохо.

Ответ 2

При любом обстоятельстве, в котором задан порядок, который задан, вы должны использовать синтаксис элемента, а не синтаксис атрибутов, чтобы представить эти свойства в вашем 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>

Согласно рекомендации XML, упорядочение атрибутов на элементе не имеет значения. Инструменты XML не обязаны сохранять порядок, в котором они появляются. Так что, если вы обработали этот элемент ComboBox с помощью XSLT-преобразования (в некоторых случаях это не сумасшедшая идея), преобразование может изменить порядок ваших атрибутов, даже если он выполняет <xsl:copy-of>. Вероятно, процессор XSLT этого не сделает, но этого не требуется.

Какой эффект повлиял бы на ранжирование порядка атрибутов каждого элемента вашего XAML на поведение вашего приложения? Ответ на этот вопрос должен быть "ничем".

Это один из аспектов XAML, который очень нервничает.

Ответ 3

В следующий раз, когда у вас возникнет проблема, подобная этому, и вы подозреваете, что привязка может быть неудачной из-за заказа. Проверьте окно вывода, отобразите все ошибки привязки, поэтому из этой ошибки вы могли бы вывести, что ItemSource был нулевым в момент привязки свойства SelectedItem