Справа от значка с глазным яблоком есть еще один значок, который позволяет блокировать элемент в визуальном конструкторе. Как и можно было догадаться, это удобно, когда нужно воспрепятствовать случайному изменению разметки XAML для заданного элемента вами или коллегами по разработке. На самом деле блокировка элемента делает его допускающим только чтение на этапе проектирования (но вы можете изменять состояние объекта во время выполнения).
Управление компоновкой содержимого с использованием панелей
Приложение WPF неизменно содержит определенное количество элементов пользовательского интерфейса (например,
элементов ввода, графического содержимого, систем меню и строк состояния), которые должны быть хорошо организованы внутри разнообразных окон. После размещения элементов пользовательского интерфейса необходимо гарантировать их запланированное поведение, когда конечный пользователь изменяет размер окна или его части (как в случае окна с разделителем). Чтобы обеспечить сохранение элементами управления WPF своих позиций внутри окна, в котором они находятся, можно задействовать множество типов панелей (также известных как диспетчеры компоновки).
По умолчанию новый WPF-элемент
Window
, созданный с помощью Visual Studio, будет применять диспетчер компоновки типа
Grid
(вскоре мы опишем его более подробно). Тем не менее, пока что рассмотрим элемент
Window
без каких-либо объявленных диспетчеров компоновки:
Title="Fun with Panels!" Height="285" Width="325">
</Window>
Когда элемент управления объявляется прямо внутри окна, в котором не используются панели, он позиционируется по центру контейнера. Рассмотрим показанное далее простое объявление окна, содержащего единственный элемент управления
Button
. Независимо от того, как изменяются размеры окна, этот виджет пользовательского интерфейса всегда будет находиться на равном удалении от всех четырех границ клиентской области. Размер элемента Button определяется установленными значениями его свойств
Height
и
Width
.
<! – - Эта кнопка всегда находится в центре окна -->
Понятно, что от окна, допускающего наличие только одного элемента управления, мало толку. Когда окно должно содержать несколько элементов, их потребуется расположить внутри любого числа панелей. В панель будут помещены все элементы пользовательского интерфейса, которые представляют окно, после чего сама панель выступает в качестве единственного объекта, присваиваемого свойству
Content
окна. Пространство имен
System.Windows.Controls
предлагает многочисленные панели, каждая из которых по-своему обслуживает внутренние элементы. С помощью панелей можно устанавливать поведение элементов управления при изменении размеров окна пользователем — будут они оставаться в тех же местах, где были размещены на этапе проектирования, располагаться свободным потоком слева направо или сверху вниз и т.д.
Элементы управления типа панелей также разрешено помещать внутрь других панелей (например, элемент управления
DockPanel
может содержать
StackPanel
со своими элементами), чтобы обеспечить высокую гибкость и степень управления. В табл. 25.2 кратко описаны некоторые распространенные элементы управления типа панелей WPF.
В последующих нескольких разделах вы узнаете, как применять распространенные типы панелей, копируя заранее определенную разметку XAML в редактор Kaxaml, который был установлен в главе 24. Все необходимые файлы XAML находятся в подкаталоге
PanelMarkup
внутри
Chapter_25
. Во время работы с Kaxaml для эмуляции изменения размеров окна нужно изменить высоту или ширину элемента
Page
в разметке.
Позиционирование содержимого внутри панелей Canvas
При наличии опыта работы с Windows Forms панель
Canvas
вероятно покажется наиболее привычной, т.к. она делает возможным абсолютное позиционирование содержимого пользовательского интерфейса. Если конечный пользователь изменяет размер окна, делая его меньше, чем размер компоновки, обслуживаемой панелью
Canvas
, то внутреннее содержимое будет невидимым до тех пор, пока контейнер не увеличится до размера, равного или превышающего размер области