Поделиться через

События изменения свойств

Windows Presentation Foundation (WPF) определяет несколько событий, создаваемых в ответ на изменение значения свойства. Часто это свойство является свойством зависимостей. Само событие может быть маршрутизируемым событием или обычным событием среды CLR, в зависимости от того, следует ли маршрутизировать событие через дерево элементов или оно должно происходить только на объекте, в котором изменилось свойство. Последний сценарий применяется, если изменение свойства относится только к объекту, в котором изменено значение свойства.

Предпосылки

В этой статье предполагается, что у вас есть базовые знания о свойствах зависимости и что вы прочитали обзор событий маршрутизации.

Определение события изменения свойства

Не все события, сообщающие об изменении свойства, явно определяются как событие изменения свойства с помощью их сигнатуры или шаблона именования. Документация по пакету SDK перекрестно ссылается на свойства с событиями и указывает, привязано ли событие непосредственно к изменению значения свойства.

Некоторые события используют тип данных события и делегат, которые специфичны для событий изменения свойств. Например, события RoutedPropertyChanged и DependencyPropertyChanged имеют определенные сигнатуры. Эти типы событий рассматриваются в следующих разделах.

События изменения маршрутизируемого свойства

События RoutedPropertyChanged имеют данные событий RoutedPropertyChangedEventArgs<T> и делегат RoutedPropertyChangedEventHandler<T>. Данные события и делегат имеют параметр универсального типа T. Фактический тип измененного свойства указывается при определении обработчика. Данные события содержат свойства OldValue и NewValue, тип среды выполнения которого совпадает с измененным свойством.

Часть "Routed" имени указывает, что событие изменения свойства регистрируется в качестве маршрутизированного события. Преимущество события изменения свойства и перенаправленного события заключается в том, что родительские элементы уведомляются при изменении свойств дочерних элементов. Это означает, что элемент верхнего уровня элемента управления получает события изменения свойства при изменении значения любой из составных частей. Например, предположим, что вы создаете элемент управления, который включает элемент управления RangeBase, как, например, Slider. Если свойство Value изменяется на элементе управления ползунка, можно выполнять обработку этого изменения в родительском элементе управления, вместо части.

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

Если ваше свойство является пользовательским свойством зависимости, или если вы работаете с производным классом, в котором вы определили код создания экземпляра, система свойств WPF предлагает лучший способ отслеживания изменений свойств. Таким образом, можно использовать встроенные обратные вызовы системы свойств CoerceValueCallback и PropertyChangedCallback. Дополнительные сведения о том, как использовать систему свойств WPF для проверки и приведения, см. в обратных вызовах зависимых свойств и проверке, а также в настраиваемых зависимых свойствах.

События изменения DependencyProperty

События DependencyPropertyChanged содержат данные события DependencyPropertyChangedEventArgs и делегат DependencyPropertyChangedEventHandler. Это стандартные события CLR, а не маршрутизируемые события. DependencyPropertyChangedEventArgs — это необычный тип отчетов о событиях, так как он не является производным от EventArgs и является структурой, а не классом.

Одним из примеров события DependencyPropertyChanged является IsMouseCapturedChanged. События DependencyPropertyChanged происходят немного чаще, чем события RoutedPropertyChanged.

Аналогично данным события RoutedPropertyChanged, данные событий DependencyPropertyChanged содержат свойства OldValue и NewValue. По причинам, упомянутых ранее, избегайте использования обработчика событий изменения свойства, чтобы снова изменить значение свойства.

Триггеры свойств

Тесно связанное понятие с событием изменения свойства является триггером свойства. Триггер свойства создается в стиле или шаблоне. Триггер свойства позволяет создать условное поведение на основе значения свойства, которому назначен триггер.

Свойство, на которое действует триггер, должно быть зависимым свойством. Это может быть, и часто это свойство зависимости только для чтения. Если свойство зависимости, предоставляемое элементом управления, имеет имя, начинающееся с "Is", это хороший признак того, что свойство по крайней мере частично предназначено для использования в триггере свойства. Свойства с таким названием часто являются свойствами зависимостей Boolean, доступными только для чтения, где основной сценарий для свойства — это отображение состояния управления. Если состояние элемента управления влияет на пользовательский интерфейс в режиме реального времени, то зависимое свойство может быть использовано как триггер свойства.

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

Ограничения триггера свойств

По сравнению с событием изменения свойства true триггеры свойств имеют некоторые ограничения.

Свойства триггеры работают с точной логикой сопоставления, где указывается имя свойства и определенное значение, которое активирует триггер. Примером является <Setter Property="IsMouseCaptured" Value="true"> ... </Setter>. Синтаксис триггера свойства ограничивает большинство случаев использования триггеров свойств до свойств Boolean или свойств, принимающих значение определенного перечисления. Диапазон возможных значений должен быть управляемым, чтобы можно было определить триггер для каждого случая. Иногда триггеры свойств существуют только для специальных значений, например, когда число элементов достигает нуля. Невозможно установить один триггер, который активируется, если значение свойства изменяется от конкретного значения, такого как ноль. Вместо использования нескольких триггеров для всех случаев, отличных от нуля, рекомендуется реализовать обработчик событий кода или поведение по умолчанию, которое переключается обратно из состояния триггера всякий раз, когда значение не является ненулевом.

Синтаксис триггера свойств аналогиен оператору if в программировании. Если условие триггера истинно, то "тело" триггера свойства "запускается". "Тело" триггера свойства не является кодом, а его разметкой. Эта разметка ограничена использованием одного или нескольких элементов Setter для задания других свойств объекта, в котором применяется стиль или шаблон.

Если условие "if" триггера свойства имеет широкий спектр возможных значений, рекомендуется задать то же значение свойства по умолчанию с помощью Setter за пределами триггера. Таким образом, установщик в триггере будет иметь приоритет, если условие триггера true, в противном случае Setter за пределами триггера будет иметь приоритет.

Триггеры свойств полезны для сценариев, когда одно или несколько свойств внешнего вида должны изменяться в зависимости от состояния другого свойства в том же элементе.

Дополнительные сведения о триггерах свойств см. в статье "Стилинг" и "Шаблон"

См. также