Главная » WPF » Z индекс

0

Для  перекрывающихся элементов  управления определено  понятие  упорядо# чения вдоль оси z – z#индекс. По умолчанию  у всех элементов  управления z#ин# декс равен 0. Перекрытие определяется взаимным  положением потомков в набо# ре  Panel.Children. С  помощью  свойства  Panel.ZIndex мы  можем  организовать

«уровни» потомков. Внутри одного уровня порядок вывода потомков на экран определяется тем, какой раньше помещен в набор; а для точного управления пе# рекрытием  можно задать несколько  уровней.

Для иллюстрации мы можем создать несколько  кнопок, задав для каждой от#

рицательное поле, чтобы все они перекрывались:

<WrapPanel>

<Button Margin=’ 5’>Button One</Button>

<Button Margin=’ 5’>Button Two</Button>

<Button Margin=’ 5’>Button Three</Button>

<Button Margin=’ 5’>Button Four</Button>

</WrapPanel>

Эта программа  формирует картинку,  изображенную на рис. 4.7 сверху. Пер# вый элемент находится в самом низу визуальной стопки. Задав z#индекс для нес# кольких кнопок, мы сможем изменить  картину:

<WrapPanel>

<Button Panel.ZIndex=’2’ Margin=’ 5’>Button One</Button>

<Button Margin=’ 5’>Button Two</Button>

<Button Panel.ZIndex=’1’ Margin=’ 5’>Button Three</Button>

<Button Margin=’ 5’>Button Four</Button>

</WrapPanel>

Отметим,  что у нескольких  элементов  значение  z#индекса одинаково  (в дан# ном случае для второй и четвертой кнопки z#индекс равен 0). Результат показан на рис. 4.7 снизу.

Рис. 4.7. Влияние z)индекса на размещение элементов управления

Реализация согласованного размещения

Мы познакомились  со многими свойствами размещения, определенными в классе FrameworkElement. С их помощью можно визуально изменить размещение, не занима# ясь программированием новой панели. Но если все#таки приходится реализовывать но# вую панель, то задача может показаться пугающе сложной, если учесть все рассмотрен# ные выше варианты поведения. К счастью, поведение целиком скрыто внутри:

public class FrameworkElement : UIElement {

public void Arrange(Rect finalRect);

protected override sealed void ArrangeCore(Rect finalRect); protected virtual Size ArrangeOverride(Size finalSize); public void Measure(Size availableSize);

protected override sealed Size MeasureCore(Size availableSize);

protected virtual Size MeasureOverride(Size availableSize);

}

Класс FrameworkElement переопределяет методы ArrangeCore и MeasureCore и вводит  новые: ArrangeOverride и MeasureOverride. Чтобы  реализовать новый менеджер размещения, поддерживающий все описанные выше паттерны, необхо# димо переопределить методы ArrangeOverride и MeasureOverride8. Прочие свой# ства размещения можно игнорировать.

Отсутствие встроенного размещения

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

8  Вспомните разговор о парах Measure/Arrange и MeasureCore/ArrangeCore и о том, как косвенный вызов последних позволяет системе выполнять какие)то функции на этапах измерения и установ) ки. В класс FrameworkElement мы добавили множество таких функций (модель слотов и т.д.) Пере) определив Core)методы и предоставив новые точки входа, мы дали разработчикам возможность переопределять только методы MeasureOverride и ArrangeOverride, не заботясь об остальных дета) лях механизма размещения.

этих свойств  определено  в классе  FrameworkElement, а не UIElement. Мы хотели провести четкую грань между контрактом  о размещении – этапах измерения и уста# новки – и реализацией конкретных менеджеров размещения.

На ранних стадиях разработки  WPF возникали горячие споры о том, как реа#

лизовывать менеджеры  размещения. Мы  считали  это критически важным  для создания системы с развитыми механизмами размещения. Хотелось получить ос# нованную  на композиции систему, которая  допускала  бы расширения. Поэтому мы решили не «зашивать»  знание о каждом менеджере в каждый элемент.

Самый удачный пример достаточно развитой,  расширяемой и основанной  на композиции системы размещения – это, пожалуй,  Windows Forms. В версии 1.0 была реализована простая модель размещения на базе события Layout. У каждо# го элемента  управления было два свойства  – Dock и Anchor, которые использо# вались для выполнения стандартного  размещения. Но чтобы реализовать специ# ализированное  размещение,   нужно  было  изобрести   какой#то  иной  механизм (быть может, на основе IExtenderProvider?), чтобы у элементов появились новые свойства.  В Windows Forms  2.0 система  размещения стала более расширяемой, улучшилась поддержка  для добавления  свойств  в элементы  управления. Впро# чем, свойства Dock и Anchor по#прежнему остались.

Чтобы не увеличивать количество  свойств элементов  до бесконечности,  все свойства, имеющие отношение  к реализации размещения, сделаны присоединен# ными (например, Canvas.Left, которое мы обсудим ниже). Присоединенные свой ства  – это механизм,  с помощью  которого  один  объект  может  наделять  неким свойством другие объекты. Поддержка  присоединенных свойств реализована с помощью класса DependencyObject, которому наследуют почти все типы в WPF.

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

Источник: К. Андерсон  Основы  Windows Presentation Foundation. Пер. с англ. А. Слинкина — М.: ДМК Пресс, 2008 — 432 с.: ил.

По теме:

  • Комментарии