Использование событий, команд и триггеров в технологиях WPF и Silverlight

События

В WPF события ведут себя точно так же, как в любой другой библиотеке классов, входящей в состав .NET. Каждый объект предоставляет набор событий, на которые можно подписаться, определив соответствующий обработчик. В WPF имеется дополнительный механизм маршрутизации событий, который позволяет им распространяться вверх по дереву элементов. Существует три вида маршрутизации событий: прямая, всплытие (bubbling) и туннелирование (tunneling). Прямые события – это простые события, возникающие от одиночного источника, они почти идентичны стандартным событиям .NET с тем отличием, что регистрируются в системе маршрутизации событий WPF. Некоторые средства платформы (например, триггеры) требуют, чтобы событие было явно зарегистрировано. Всплывающие и туннельные события – две стороны одной медали: туннельные события продвигаются от корня дерева к целевому элементу, а всплывающие – в обратном направлении. Обычно эти два вида событий встречаются попарно, причем туннельная версия имеет префикс Preview. Большинство событий ввода (от клавиатуры, от мыши и от пера) имеют как туннельную, так и всплывающую версии, например: MouseRightButtonDown и PreviewMouseRightButtonDown, соответственно.

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

<Window ...
   PreviewMouseRightButtonDown=’WindowPreviewRightButtonDown’
    MouseRightButtonDown=’WindowRightButtonDown’>
    <GroupBox
        >PreviewMouseRightButtonDown=’GroupBoxPreviewRightButtonDown’
        MouseRightButtonDown=’GroupBoxRightButtonDown’>
       <StackPanel>
           <Button>One</Button>
           <Button
               PreviewMouseRightButtonDown=’ButtonTwoPreviewRightButtonDown’
               MouseRightButtonDown=’ButtonTwoRightButtonDown’>
              Two
           </Button>
        </StackPanel>
    </GroupBox>
</Window>

В обработчике каждого события мы можем вывести его имя:

void ButtonTwoPreviewRightButtonDown(object sender, MouseButtonEventArgs e)
{
    Debug.WriteLine("ButtonTwo PreviewRightButtonDown");
}

void ButtonTwoRightButtonDown(object sender, MouseButtonEventArgs e)
{
    Debug.WriteLine("ButtonTwo RightButtonDown");
}

void GroupBoxPreviewRightButtonDown(object sender, MouseButtonEventArgs e)
{
    Debug.WriteLine("GroupBox PreviewRightButtonDown");
}

void GroupBoxRightButtonDown(object sender, MouseButtonEventArgs e)
{
    Debug.WriteLine("GroupBox RightButtonDown");
}

void WindowPreviewRightButtonDown(object sender, MouseButtonEventArgs e)
{
    Debug.WriteLine("Window PreviewRightButtonDown");
}

void WindowRightButtonDown(object sender, MouseButtonEventArgs e)
{
    Debug.WriteLine("Window RightButtonDown");
}

Во время работы этой программы события возникают в следующем порядке:

1. Window PreviewMouseRightButtonDown.
2. Window PreviewMouseRightButtonDown.
3. GroupBox PreviewMouseRightButtonDown.
4. Button PreviewMouseRightButtonDown.
5. Button MouseRightButtonDown.
6. GroupBox MouseRightButtonDown.
7. Window MouseRightButtonDown.

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

Если мы хотим получать извещения о нажатии любой кнопки в окне, достаточно просто вызвать метод AddHandler. У каждого события в WPF имеется свойство типа RoutedEvent, которое во время исполнения ссылается на объект источник. Чтобы присоединить обработчик, мы передаем методу AddHandler объект RoutedEvent и делегат, который необходимо вызвать:

this.AddHandler(Button.ClickEvent, (RoutedEventHandler)delegate 
{
    MessageBox.Show("Clicked"); 
});

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

Команды

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

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

<MenuItem Header=’_File’>
    <MenuItem Header=’E_xit’ Click=’ExitClicked’ />
</MenuItem>

В файле с кодом реализуем обработчик события:

void ExitClicked(object sender, RoutedEventArgs e)
{
    Application.Current.Shutdown();
}

Пока все хорошо, но давайте еще добавим текст, в который входит гиперссылка, позволяющая выйти из программы:

<TextBlock>
    Вас приветствует моя программа. Если вам надоело, можете
    <Hyperlink Click=’ExitClicked’>выйти</Hyperlink>.
</TextBlock>

Вот теперь начинаются неприятности. Мы делаем слишком много предположений о реализации метода ExitClicked, например, что его сигнатура совместима с событием Hyperlink.Click и что он не делает ничего другого, кроме завершения приложения. К тому же, в разметку оказались зашиты произвольно выбранные имена методов из файла с кодом, а дизайнер, который конструирует пользовательский интерфейс, не будет знать, к каким обработчикам событий привязаться.

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

• определить назначение команды;
• написать реализацию команды;
• создать для команды триггер.

Основой всех команд в WPF является довольно простой интерфейс ICommand:

public interface ICommand 
{
    event EventHandler CanExecuteChanged;
    bool CanExecute(object parameter);
    void Execute(object parameter);
}

Метод CanExecute позволяет выяснить, находится ли команда в таком состоянии, когда ее можно выполнить. Обычно элементы управления пользуются этим методом, чтобы активировать или деактивировать себя. Иными словами, если ассоциированная с кнопкой команда возвращает false из метода CanExecute, то кнопка деактивируется. Такое обобществление понятия "активен" позволяет нескольким элементам, связанным с одной командой, поддерживать согласованное состояние. Метод Execute основной, его вызов означает выполнение команды. Реализация класса Button (как и любого другого элемента управления, поддерживающего команды) должна включать примерно такой код:

protected virtual void OnClick(RoutedEventArgs e)
{
    if (Command != null && Command.CanExecute(CommandParameter))
    {
        Command.Execute(CommandParameter);
    }
// ... продолжение реализации
}

Для определения новой команды мы должны реализовать интерфейс ICommand. Поскольку мы хотим, чтобы наша команда закрывала приложение, то можем вызвать метод Shutdown:

public class Exit: ICommand
{
    public bool CanExecute(object parameter)
    {
        return true;
    }

    public event EventHandler CanExecuteChanged;

    public void Execute(object parameter)
    {
        Application.Current.Shutdown();
    }
}

Для привязки команды к пункту меню или к ссылке мы указываем в свойстве Command имя команды – Exit:

<MenuItem Header=’_File’>
    <MenuItem Header=’E_xit’>
        <MenuItem.Command>
            <l:Exit />
        </MenuItem.Command>
    </MenuItem>
</MenuItem>
...
<Hyperlink>
    <Hyperlink.Command><l:Exit /></Hyperlink.Command>
    ...
</Hyperlink>

Так как команда часто вызывается из нескольких мест, принято заводить статическое поле, содержащее экземпляр команды:

public partial class Window1: Window
{
    public static readonly ICommand ExitCommand = new Exit();
    ...
}

Дополнительный плюс такой реализации заключается в том, что реализацию класса Exit можно скрыть, объявив, что поле имеет тип ICommand. Теперь Exit можно сделать закрытым классом, а в разметке привязаться к статическому полю:

<MenuItem Header=’_File’>
    <MenuItem Header=’E_xit’ Command=’{x:Static l:Window1.ExitCommand}’ />
</MenuItem>

Таким образом, наше окно может раскрывать свою функциональность в виде команд. Однако, тут имеется интересная проблема. Сейчас команда Exit реализована на глобальном уровне; мы можем вызвать ее из любого места и тем самым завершить приложение. Предположим, однако, что "exit" должно означать закрытие текущего окна. В таком случае хотелось бы отделить реализацию выхода от определения, как это было с событиями.

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

class Exit : ICommand
{
    public static readonly RoutedEvent ExecuteEvent =
       EventManager.RegisterRoutedEvent(
                "Execute",
                 RoutingStrategy.Bubble,
                 typeof(RoutedEventHandler),
                 typeof(Exit));
...
}

Поскольку для этого события задана стратегия Bubble, оно будет всплывать от источника. Чтобы возбудить событие, мы изменим реализацию метода Execute, так чтобы он искал текущий элемент (в данном примере мы воспользовались для этой цели методом Keyboard.FocusedElement, но могли бы остановиться на любом механизме обнаружения "текущего"), а затем возбуждал подходящее событие:

public void Execute(object parameter)
{
    RoutedEventArgs e =
        new RoutedEventArgs(Exit.ExecuteEvent, Keyboard.FocusedElement);
    Keyboard.FocusedElement.RaiseEvent(e);
}

Это подводит нас к идее привязки команд – возможности отделить реализацию команды от ее назначения. Вернемся к классу Window1 и добавим в него реализацию команды:

public partial class Window1: Window
{
    ...
    public Window1()
    {
        InitializeComponent();
        AddHandler(Exit.ExecuteEvent, ExitExecuted);
    }

    void ExitExecuted(object sender, RoutedEventArgs e)
    {
        this.Close();
    }
}

Тут возможно некоторое недопонимание. Напомним, что цель команды – предложить абстракцию того, что должно происходить. В данном случае элемент управления (скажем, MenuItem) вызывает команду в ответ на событие (к примеру, Click). При нашей реализации команда Exit возбудит событие Execute, которое распространится по дереву элементов, а объект Window сможет подписаться на него и выполнить те или иные действия:

1. Пользователь щелкает по пункту меню.
2. MenuItem вызывает метод Execute команды.
3. Реализация команды Exit возбуждает событие Exit.Execute от имени элемента, имеющего фокус (в данном случае MenuItem).
4. Событие всплывает вверх по дереву.
5. Window получает событие Exit.Execute.
6. Window выполняет обработчик события (закрывает окно).

Можно было бы пойти дальше и включить в интерфейс ICommand средства поддержки привязок к вводу (для обработки ввода с клавиатуры, от мыши и пера), параметров и прочего. Однако в каркасе есть встроенный класс RoutedCommand, который большую часть всего этого уже умеет делать. Маршрутизируемые команды позволяют полностью отделить реализацию команды от ее назначения. Паттерн определения новой команды похож на RoutedEvent и DependencyProperty. Команда определяется как статическое свойство; это просто уникальный маркер, обозначающий ее идентичность:

public partial class Window1: Window
{
    public static readonly ICommand ExitCommand =
        new RoutedCommand("Exit", typeof(Window1));
    ...
}

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

public Window1()
{
    InitializeComponent();
    CommandBindings.Add(new CommandBinding(ExitCommand, ExitExecuted));
}

void ExitExecuted(object sender, ExecutedRoutedEventArgs e)
{
    this.Close();
}

Привязка к команде позволяет решить, следует ли активировать команду, а также с помощью свойства InputBindings отобразить на команду действия по вводу данных:

<Window x:Class=’EssentialWPF.Window1’
    xmlns=’http://schemas.microsoft.com/winfx/2006/xaml/presentation’
    xmlns:x=’http://schemas.microsoft.com/winfx/2006/xaml’
    xmlns:l=’clr_namespace:EssentialWPF’
    Title=’EssentialWPF’>

<Window.InputBindings>
    <KeyBinding Key=’A’ Modifiers=’Control’
        Command=’{x:Static l:Window1.ExitCommand}’ />
</Window.InputBindings>
...
</Window>

Еще одна существенная особенность – это понятие о "безопасных командах". С некоторыми командами, например вырезания, копирования и вставки, сопряжены определенные угрозы. С целью гарантировать, что система выполняет такие операции только по явному запросу пользователя (или если разрешает система управления цифровыми правами), класс RoutedCommand может отслеживать, была ли команда инициирована пользователем.

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