После всех вызовов GenericMouseDown () был опять-таки вызван обработчик событий Window MouseUp().

Последний щелчок был выполнен на кнопке Button. В этот раз обработчик GenericMouseDown () был вызван только три раза. После этого сработало событие Button. Click, которое привело к вызову clickMeButtonClick (). Но в завершение был снова вызван обработчик событий WindowMouseUp ().

В последней цепочке событий произошло следующее: событие MouseDown было обработано кнопкой и использовано для генерации ее события Click. В рамках базовой реализации обработчика событий MouseDown кнопки для свойства Handled параметра аргументов события RoutedEventArgs было установлено значение true. Это привело к прерыванию потока событий, в результате чего событие MouseDown не было передано обратно вверх по иерархии элементов управления.

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

Подключаемые события

в предыдущем примере событие Button.Click было добавлено к элементу управления Button. Обработчиков для события Click элементов управления Grid и Window мы не добавляли, потому что у них нет события Click. Однако иногда может потребоваться, чтобы оно у них было.

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

В WPF предлагается альтернативный (и более удобный) способ для разрешения подобных ситуаций, и заключается он в применении подключаемых событий. С помощью системы подключаемых событий обрабатывать события можно даже в тех элементах управления, которые их не предоставляют, т.е. в рассматриваемом примере можно было бы обработать событие Button.Click в содержащем кнопки элементе управления Grid, даже несмотря на то, что у этого элемента управления нет события Click. На самом деле это было бы событие ButtonBase.Click, поскольку ButtonBase представляет собой класс, который определяет событие Click, наследуемое элементом управления Button.

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

<Grid Name= contentGrid ButtonBase.Click= contentGrid Click ...> <Button Name= buttonl ...>Buttonl</Button> <Button Name= button2 ...>Button2</Button>

<Button Name= buttonlOOO ...>Buttonl000</Button> </Grid>

В обработчике событий мы получаем ссылку на элемент управления Grid в параметре отправителя, а, значит, можем использовать свойство RoutedEventArgs. Source для определения того, на какой кнопке был выполнен щелчок, и реагировать соответствующим образом. Эта событие все равно будет генерироваться только при выполнении щелчка на кнопке, а не на фоновой области элемента управления Grid, поскольку у элемента управления Grid нет события Click, которое он мог бы генерировать.

Компоновка элементов управления

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

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

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

□ DockPanel. Этот элемент управления позволяет пристыковывать дочерние элементы управления к одному из четырех краев. Последний дочерний элемент занимает оставшееся пространство.

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

□ StackPanel. Этот элемент управления позволяет размещать дочерние элементы в последовательном горизонтальном или вертикальном порядке.

□ WrapPanel. Этот элемент управления так же, как и StackPanel, позволяет размещать дочерние элементы управления в последовательном горизонтальном или вертикальном порядке, но виде не одной, а нескольких строк или столбцов в соответствии с доступным пространством.

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

□ Что подразумевается под стопочным порядком размещения элементов управления.

□ Как использовать свойства типа Alignment, Margin и Padding для размещения элементов управления и их содержимого.

□ Как применять элемент управления Border.

Стопочный порядок размещения элементов управления

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

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

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

Свойства HorizontalAllgnment, VerticalAligzment, Margin, Padding, Height и Width

В более ранних примерах уже показывалось, как, комбинируя свойства Margin, HorizontalAlignment и VerticalAlignment, можно размещать элементы управления в контейнере Grid желаемым образом, а также как с использованием свойств Height и Width задавать их размеры. Все эти свойства, вместе с еще не рассматривавшимся свойством Padding, являются полезными для всех элементов управления компоновкой (или, по крайней мере, большинства из них, как будет показано позже), но разным образом. Некоторые из элементов управления компоновкой могут также устанавливать для этих свойств значения по умолчанию. Во всем этом можно будет убедиться на примерах, которые будут приводиться в последующих разделах, а пока что необходимо разобраться в основных деталях.

Свойства HorizontalAlignment и VerticalAlignment отвечают за то, как должен выравниваться элемент управления, но какие значения для них можно устанавливать еще не показывалось. Для свойства HorizontalAlignment, например, можно устанавливать такие значения, как Left, Right, Center и Stretch. Значения Left и Right позволяют размещать элементы управления, соответственно, с левого или с правого края контейнера, значение Center - посередине, а значение Stretch дает возможность изменять ширину элемента управления так, чтобы его края достигали сторон контейнера. Свойство VerticalAlignment выглядит похоже и может принимать значения Тор, Bottom, Center и Stretch.

Свойства Margin и Padding отвечают за количество пространства, которое должно оставляться пустым, соответственно, снаружи и изнутри краев элементов управления. В приводившихся ранее примерах свойство Margin использовалось для размещения элементов управления относительно, например, левого верхнего угла контейнера Grid. Это работало потому, что в случае установки для свойства HorizontalAlignment значения Left, а для свойства VerticalAlignment - значения Тор, элемент управления пристыковывается прямо к левому верхнему углу, а свойство Margin приводило к добавлению пробелов снаружи этого элемента управления. Свойство Padding имеет похожее предназначение, но только отделяет пробелами содержимое элемента управления от его краев. Оно особенно полезно для элемента управления Border, о котором