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

□ Разработчик может использовать стили для изменения значений свойств зависимостей.

□ Разработчик может устанавливать значение свойства зависимости за счет использования ресурсов или привязки данных.

□ Разработчик может изменять значения свойств зависимостей в анимации.

□ Разработчик может устанавливать свойства зависимостей иерархическим образом в XAML - т.е. значение, которое устанавливается для свойства зависимости в родительском элементе, может использоваться для установки значения по умолчанию для такого же свойства зависимости в его дочерних элементах.

□ Разработчик может конфигурировать уведомления об изменениях в значениях свойств зависимостей путем применения четко определенной схемы кодирования.

□ Разработчик может конфигурировать целые наборы взаимосвязанных свойств для того, чтобы они все обновлялись в ответ на изменение в любом из них. Этот процесс называется приведением (coercion), потому что измененное свойство приводит значения остальных свойств.

□ Разработчик может применять к свойству зависимости метаданные для указания других связанных с поведением характеристик. Например, он может указывать таким образом, что изменение конкретного свойства чревато возникновением необходимости в перестройке пользовательского интерфейса.

На практике из-за способа, которым реализуются свойства зависимостей, на первый взгляд можно и не заметить особых отличий от обычных свойств. Однако при создании своих собственных элементов управления сразу же станет заметно, что в случае использования обычных свойств .NET многие функциональные возможности вдруг куда-то исчезают.

Из-за того, что свойства зависимостей играют превалирующую роль в WPF, чуть позже в этой главе будет показано, как именно их реализовать.

Подключаемые свойства

Подключаемое свойство (attached property) - это свойство, которое делается доступным для каждого дочернего объекта в экземпляре того класса, который его определяет. Например, представим, что у нас есть класс под названием Recipe (Рецепт) с дочерними объектами, представляющими различные ингредиенты. Тогда мы могли определить в нем подключаемое свойство и затем использовать его в каждом дочернем объекте. Важно обратить внимание на то, что указывать значения для подключаемых свойств в дочерних объектах не нужно.

Главная причина, по которой могло бы возникнуть желание сделать подобное, состоит в том, что XAML-код, который нужно использовать для установки значений для подключаемых свойств, является очень простым для понимания:

<Recipe Name= Simple Vegetable Chili > <TinOfKidneyBeans Recipe.Quantity= 2 Mashed= true /> <TinOfChoppedTomatoes Recipe.Quantity= 2 />

<FreshChili Recipe.Quantity= 5 Notes= Chopped fine, vary to taste. /> <Onion Recipe.Quantity= l Notes= Chopped and fried m olive oil. /> <LBVPort Notes= Just a dash. /> </Recipe>

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

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

Маршрутизируемые события

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

Замечательным примером может служить ситуация, когда пользователям предоставляется возможность взаимодействовать с приложениями с помощью мыши, что, несомненно, случается очень часто. При выполнении пользователем щелчка на кнопке в приложении обычно нужно, чтобы приложение как-то реагировало на событие щелчка. Одним из возможных вариантов для обеспечения такого поведения, который уже знаком по разработке приложений Windows Forms и ASP.NET, является добавление обработчика для предоставляемого кнопкой события и указания в нем тех действий, которые должны выполняться в ответ на щелчок.

Хотя на первый взгляд этого не видно, но данный подход на самом деле прилично ограничивает возможности разработчика и может приводить к получению, например, в некоторых приложениях Windows Forms, довольно запутанного кода. Объясняется это необходимостью в существовании некоего механизма для определения того, какой элемент управления должен реагировать на щелчок кнопкой мыши генерацией своего события щелчка, а этот элемент управления может и не быть очевиден сразу. Например, если взять приведенный здесь простой пример, то какой элемент управления должен генерировать событие щелчка - сама кнопка или окно (т.е. элемент Window), в котором она содержится? При наличии обработчиков событий и у кнопки, и у элемента Window и необходимости, чтобы событие генерировал только какой-то один из них, пожалуй, будет лучше выбрать кнопку. Однако как же быть, если требуется, чтобы событие генерировали они оба, да еще и в определенном порядке? В случае приложений Windows Forms для получения такого поведения, скорее всего, придется писать специальный (и вероятно довольно сложный) код.

В WPF событие щелчка кнопкой мыши реализуется для элементов управления. Button и Window включительно, в виде маршрутизируемого события, что полностью исключает упомянутую проблему. Маршрутизируемые события генерируются всеми объектами в иерархии в определенном порядке, предоставляя разработчику полный контроль над тем, как на них реагировать. Например, рассмотрим элемент управления Window, содержащий элемент управления Grid, который, в свою очередь, содержит элемент управления Rectangle. При выполнении щелчка на элементе управления Rectangle будет происходить следующая последовательность событий.

1. Генерация события нажатия кнопки мыши в Window.

2. Генерация события нажатия кнопки мыши в Grid.

3. Генерация события нажатия кнопки мыши в Rectangle.

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

4. Генерация еще одного события нажатия кнопки мыши в Rectangle.

5. Генерация еще одного события нажатия кнопки мыши в Grid.

6. Генерация еще одного события нажатия кнопки мыши в Window.

Разработчик может реагировать на событие в любой точке приведенной последовательности, просто добавляя соответствующий метод обработки событий. Еще он также может прерывать эту последовательность в любой точке в рамках обработчика событий, но по умолчанию обработчики событий не предусматривают ее прерывания. Это означает, что разработчик может запускать сразу несколько методов обработки из одного события (в данном случае - одного события нажатия кнопки мыши).

Изучая показанную здесь последовательность событий, не помешает познакомиться с некоторыми полезными терминами, которые применяются в WPF в отношении событий. Те события, которые продвигаются вниз по иерархии элементов управления, называются туннельными (tunneling), или нисходящими, а те, которые поднимаются вверх - пузырьковыми (bubbling), или восходящими.

Вдобавок, где бы не использовались маршрутизируемые события в WPF, их имена всегда указывают на то, какими они являются - туннельными или пузырьковыми. Имена всех туннельных событий начинаются с префикса Preview. Например, у элемента управления Window есть и событие с именем MouseDown, и событие с именем PreviewMouseDown. Добавлять обработчики можно как только для какого-нибудь одного из них, так и для сразу обоих или, при желании, вообще никакого из них.

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

Обработчики маршрутизируемых событий принимают два параметра: источник события и экземпляр объекта RoutedEventArgs или того класса, который наследуется от RoutedEventArgs.

Window PreviewMouseDown

Туннелирование (Т) Grid PreviewMouseDown

Элемент управления Window

Элемент управления Grid

Window.MouseDown (б) Пузырьковая передача

Grid MouseDown (ь

Туннелирование 3 Rectangle PreviewMouseDown

Элемент управления Rectangle

Пузырьковая передача

Rectangle.MouseDown (Т)

Рис. 34.9. Последовательность событий