Подводя итог, следует отметить, что свойства зависимости выглядят как обычные свойства, когда вы извлекаете или устанавливаете их значения в разметке XAML либо в коде, но "за кулисами" они реализованы с помощью гораздо более замысловатых программных приемов. Вспомните, что основным назначением этого процесса является построение специального элемента управления, имеющего специальные свойства, которые должны быть интегрированы со службами WPF, требующими взаимодействия через свойства зависимости (например, с анимацией, привязкой данных и стилями).
Несмотря на то что часть реализации свойства зависимости предусматривает определение оболочки CLR, вы никогда не должны помещать логику проверки достоверности в блок set. К тому же оболочка CLR свойства зависимости не должна делать ничего кроме вызовов GetValue
SetValue.Исполняющая среда WPF сконструирована таким образом, что если написать разметку XAML, которая выглядит как установка свойства, например:
то исполняющая среда вообще обойдет блок установки свойства Height
SetValue! Причина такого необычного поведения связана с простым приемом оптимизации. Если бы исполняющая среда WPF обращалась к блоку установки свойства Height, то ей пришлось бы во время выполнения выяснять посредством рефлексии, где находится поле DependencyProperty (указанное в первом аргументе SetValue), ссылаться на него в памяти и т.д. То же самое остается справедливым и при написании разметки XAML, которая извлекает значение свойства Height — метод GetValue будет вызываться напрямую. Но раз так, тогда зачем вообще строить оболочку CLR? Дело в том, что XAML в WPF не позволяет вызывать функции в разметке, поэтому следующий фрагмент приведет к ошибке:На самом деле установку или получение значения в разметке с применением оболочки CLR следует считать способом сообщения исполняющей среде WPF о необходимости вызова методов GetValue/SetValue
Button b = new Button;
b.Height = 10;
В таком случае, если блок set
Height содержит какой-то код помимо вызова SetValue, то он Запомните основное правило: при регистрации свойства зависимости используйте делегат ValidateValueCallback
Построение специального свойства зависимости
Если к настоящему моменту вы слегка запутались, то такая реакция совершенно нормальна. Создание свойств зависимости может требовать некоторого времени на привыкание. Как бы то ни было, но это часть процесса построения многих специальных элементов управления WPF, так что давайте рассмотрим, каким образом создается свойство зависимости.
Начните с создания нового проекта приложения WPF по имени CustomDependencyProperty
ShowNumberControl.xaml.На заметку!
Более подробные сведения о классеUserControl в WPF ищите в главе 27, а пока просто следуйте указаниям по мере проработки примера.Подобно окну типы UserControl
Label внутри Grid: 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">
Background="LightBlue"/>
В файле кода для данного элемента создайте обычное свойство .NET Core, которое упаковывает поле типа int
Content элемента Label:public partial class ShowNumberControl : UserControl
{
public ShowNumberControl
{
InitializeComponent;
}
// Обычное свойство .NET Core.
private int _currNumber = 0;
Бьёрн Страуструп , Ирина Сергеевна Козлова , Бьерн Страуструп , Валерий Федорович Альмухаметов
Программирование, программы, базы данных / Базы данных / Программирование / Учебная и научная литература / Образование и наука / Книги по IT