Язык программирования C#9 и платформа .NET5 - Эндрю Троелсен

такие сведения могут показаться избыточными (в конце концов, поле HeightProperty уже определено внутри класса FrameworkElement), это довольно продуманный аспект WPF, поскольку он позволяет одному классу регистрировать свойства в другом классе (даже если его определение было запечатано).

Четвертый аргумент, передаваемый методу DependencyProperty.Register() в рассмотренном примере, представляет собой то, что действительно делает свойства зависимости уникальными. Здесь передается объект FrameworkPropertyMetadata, который описывает разнообразные детали относительно того, как инфраструктура WPF должна обрабатывать данное свойство в плане уведомлений с помощью обратных вызовов (если свойству необходимо извещать других, когда его значение изменяется). Кроме того, объект FrameworkPropertyMetadata указывает различные параметры (представленные перечислением FrameworkPropertyMetadataOptions), которые управляют тем, на что свойство воздействует (работает ли оно с привязкой данных, может ли наследоваться и т.д.). В данном случае аргументы конструктора FrameworkPropertyMetadata можно описать так:

new FrameworkPropertyMetadata(

  // Стандартное значение свойства.

  (double)0.0,

  // Параметры метаданных.

  FrameworkPropertyMetadataOptions.AffectsMeasure,

  // Делегат, который указывает на метод,

  // вызываемый при изменении свойства.

  new PropertyChangedCallback(FrameworkElement.OnTransformDirty)

)

Поскольку последний аргумент конструктора FrameworkPropertyMetadata является делегатом, обратите внимание, что он указывает на статический метод OnTransformDirty() класса FrameworkElement. Код метода OnTransformDirty() здесь не приводится, но имейте в виду, что при создании специального свойства зависимости всегда можно указывать делегат PropertyChangeCallback, нацеленный на метод, который будет вызываться в случае изменения значения свойства.

Это подводит к финальному параметру метода DependencyProperty.Register() — второму делегату типа ValidateValueCallback, указывающему на метод класса FrameworkElement, который вызывается для проверки достоверности значения, присваиваемого свойству:

new ValidateValueCallback(FrameworkElement.IsWidthHeightValid)

Метод IsWidthHeightValid() содержит логику, которую обычно ожидают найти в блоке установки значения свойства (как более подробно объясняется в следующем разделе):

private static bool IsWidthHeightValid(object value)

{

  double num = (double) value;

  return ((!DoubleUtil.IsNaN(num) && (num >= 0.0))

    && !double.IsPositiveInfinity(num));

}

После того, как объект DependencyProperty зарегистрирован, остается упаковать поле в обычное свойство CLR (Height в рассматриваемом случае). Тем не менее, обратите внимание, что блоки get и set не просто возвращают или устанавливают значение double переменной-члена уровня класса, а делают это косвенно с использованием методов GetValue() и SetValue() базового класса System.Windows.DependencyObject:

public double Height

{

  get { return (double) base.GetValue(HeightProperty); }

  set { base.SetValue(HeightProperty, value); }

}

Важные замечания относительно оболочек свойств CLR

Подводя итог, следует отметить, что свойства зависимости выглядят как обычные свойства, когда вы извлекаете или устанавливаете их значения в разметке XAML либо в коде, но "за кулисами" они реализованы с помощью гораздо более замысловатых программных приемов. Вспомните, что основным назначением этого процесса является построение специального элемента управления, имеющего специальные свойства, которые должны быть интегрированы со службами WPF, требующими взаимодействия через свойства зависимости (например, с анимацией, привязкой данных и стилями).

Несмотря на то что часть реализации свойства зависимости предусматривает определение оболочки CLR, вы никогда не должны помещать логику проверки достоверности в блок set. К тому же оболочка CLR свойства зависимости не должна делать ничего кроме вызовов GetValue() или SetValue().

Исполняющая среда WPF сконструирована таким образом, что если написать разметку XAML, которая выглядит как установка свойства, например:

<Button x:Name="myButton" Height="100" .../>

то исполняющая среда вообще обойдет блок установки свойства Height и напрямую вызовет метод SetValue()! Причина такого необычного поведения связана с простым приемом оптимизации. Если бы исполняющая среда WPF обращалась к блоку установки свойства Height, то ей пришлось бы во время выполнения выяснять посредством рефлексии, где находится поле DependencyProperty (указанное в первом аргументе SetValue()), ссылаться на него в памяти и т.д. То же самое остается справедливым и при написании разметки XAML, которая извлекает значение свойства Height — метод GetValue() будет вызываться напрямую. Но раз так, тогда зачем вообще строить оболочку CLR? Дело в том, что XAML в WPF не позволяет вызывать функции в разметке, поэтому следующий фрагмент приведет к ошибке:

<!-- Ошибка! Вызывать методы в XAML-разметке WPF нельзя! -->

<Button x:Name="myButton" this.SetValue("100") .../>

На самом деле установку или получение значения в разметке с применением оболочки CLR следует считать способом сообщения исполняющей среде WPF о необходимости вызова методов GetValue()/SetValue(), т.к. напрямую вызывать их в разметке невозможно. А что, если обратиться к оболочке CLR в коде, как показано ниже?

Button b = new Button();

b.Height = 10;

В таком случае, если блок set свойства Height содержит какой-то код помимо вызова SetValue(), то он должен выполниться, потому что оптимизация синтаксического анализатора XAML в WPF не задействуется.

Запомните основное правило: при регистрации свойства зависимости используйте делегат ValidateValueCallback для указания на метод, который выполняет проверку достоверности данных. Такой подход гарантирует корректное поведение независимо от того, что именно применяется для получения/установки свойства зависимости — разметка XAML или код.

Построение специального свойства зависимости

Если к настоящему моменту вы слегка запутались, то такая реакция совершенно нормальна. Создание свойств зависимости может требовать некоторого времени на привыкание. Как бы то ни было, но это часть процесса построения многих специальных элементов управления WPF, так что давайте рассмотрим, каким образом создается свойство зависимости.

Начните с создания нового проекта приложения WPF по имени CustomDependencyProperty. Выберите в меню Project (Проект) пункт Add User Control (WPF) (Добавить пользовательский элемент управления (WPF)) и создайте элемент управления с именем ShowNumberControl.xaml.

На заметку! Более подробные сведения о классе UserControl в WPF ищите в главе 27, а пока просто следуйте указаниям по мере проработки примера.

Подобно окну типы UserControl в WPF имеют файл XAML и связанный файл кода. Модифицируйте разметку XAML пользовательского элемента управления, чтобы определить простой элемент Label внутри Grid:

<UserControl x:Class="CustomDepProp.ShowNumberControl"

  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

  xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

  xmlns:local="clr-namespace: CustomDependencyProperty"

  mc:Ignorable="d"

  d:DesignHeight="300" d:DesignWidth="300">

  <Grid>

    <Label x:Name="numberDisplay" Height="50" Width="200"

      Background="LightBlue"/>

  </Grid>

</UserControl>

В файле кода для данного элемента создайте обычное свойство .NET Core, которое упаковывает поле типа int и устанавливает