Вопросы порядка определения атрибутов XAML Silverlight - PullRequest
Новая
       8

Вопросы порядка определения атрибутов XAML Silverlight

15 голосов
/ 19 августа 2009

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

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

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

Ответы [ 3 ]

16 голосов
/ 20 августа 2009

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

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

5 голосов
/ 11 октября 2009

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

2 голосов
/ 21 августа 2009

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

...