Подсистема Windows Presentation Foundation (wpf) в этой главе



Скачать 325.41 Kb.
Pdf просмотр
страница1/3
Дата24.12.2016
Размер325.41 Kb.
Просмотров484
Скачиваний0
  1   2   3

18
Подсистема Windows
Presentation Foundation (WPF)
В
ЭТОЙ ГЛАВЕ
...

Основы языка XAML

Создание WPF приложения

Настройка стиля WPF приложения

Внедрение WPF контента в проект Windows Forms

Внедрение контента проекта Windows Forms в WPF проект

Использование визуализатора WPF
Начиная разработку нового клиентского приложения для системы Windows с по мощью интегрированной среды Visual Studio, пользователь может выбрать одну из двух технологий: Windows Forms или Windows Presentation Foundation (WPF). Это со вершенно разные интерфейсы прикладного программирования для управления сло ем презентации пользовательского приложения. Технология WPF чрезвычайно мощ ная и гибкая. Она была разработана для преодоления недостатков и ограничений,
присущих технологии Windows Forms. Во многих аспектах технология WPF является преемником Windows Forms. Однако овладение этой мощной и гибкой подсистемой требует от разработчика больших усилий, поскольку она заметно отличается от сво его предшественника.
В главе описывается процесс создания простого WPF приложения с помощью ин тегрированной среды Visual Studio 2010. Подробное описание технологии WPF выхо дит за рамки рассмотрения данной книги, так как для этого потребовалось бы слиш ком много места. Вместо этого мы приводим обзор возможностей системы Visual Stu dio 2010, помогающих быстро создавать пользовательские интерфейсы с помощью языка XAML.
Стр. 391
Стр. 391

392
Часть IV. Расширенные клиентские приложения
392
Что такое WPF
Windows Presentation Foundation — это презентационный функциональный слой для системы Windows. Что же делает его уникальным и почему его следует считать достой ной альтернативой подсистеме Windows Forms? В то время, как подсистема Windows
Forms для рендеринга использует растровые механизмы GDI/GDI+, подсистема WPF
имеет свой собственный векторный механизм рендеринга. По этой причине она не соз дает окна и элементы управления стандартным способом и в стандартном виде, прису щем системе Windows. Технология WPF радикально отличается от технологии Windows
Forms. В графической подсистеме Windows Forms разработчик обычно определял поль зовательский интерфейс с помощью визуального конструктора, автоматически генери руя код (на языке проекта) в файле с расширением
.designer
. Таким образом, по суще ству, пользовательский интерфейс определялся и управлялся кодом на языке C# или VB.
В то же время пользовательский интерфейс, созданный по технологии WPF, фактиче ски определяется языком разметки Extensible Application Markup Language, который обычно называют XAML (произносится как “zammel”). Этот язык основан на языке
XML и специально разработан компанией Microsoft для использования в системе WPF.
Именно язык XAML, лежащий в основе технологии WPF, обеспечивает ее мощь и гибкость, позволяя разрабатывать намного более богатые и особенные пользователь ские интерфейсы по сравнению с технологией Windows Forms. Определение пользова тельского интерфейса с помощью языка XAML является одинаковым для любого языка проекта. По этой причине наряду с новыми возможностями управления пользователь ским интерфейсом появилось большое количество новых вспомогательных концепций,
влияющих на код. Например, возникли свойства зависимостей, значениями которых являются выражения, что часто требуется во многих сценариях связывания для под держки сложных возможностей связывания, предоставляемых языком XAML. Тем не менее код в WPF приложении почти не отличается от кода стандартного приложения,
созданного по технологии Windows Forms, — основное внимание разработчику следует уделить языку XAML.
При разработке WPF приложений необходимо думать совершенно иначе, чем при разработке приложений по технологии Windows Forms. Разработчик должен сконцен трировать свое внимание на преимуществах новых возможностей связывания, предос тавляемых языком XAML, и рассматривать свой код не как контроллер пользователь ского интерфейса, а как обслуживающий механизм. Теперь код не должен “протал кивать” данные в пользовательский интерфейс и говорить ему, что делать. Вместо этого пользовательский интерфейс должен спрашивать у кода, что делать, и посылать ему за просы на данные (т.е. “выталкивать” их из него). Разница почти незаметна, но способ определения презентационного слоя приложения изменяется радикально. Представьте себе, что пользовательский интерфейс теперь начальник. Код может (и должен) при нимать решения, но больше не должен инициировать действия.
Это “новое мышление” порождает новые шаблоны проектирования, описываю щие взаимодействие кода и элементов пользовательского интерфейса, такие как по пулярный шаблон Model View ViewModel (MVVM), позволяющий намного лучше про водить модульное тестирование кода, обслуживающего пользовательский интерфейс и поддерживающего явное разделение между элементами проектировщика и разра ботчика в рамках проекта. В результате изменяется способ написания кода, и в ито ге — способ проектирования приложения. Такое явное разделение упрощает работу проектировщика и разработчика, позволяя проектировщику работать с помощью
Стр. 392
Стр. 392

Глава 18. Подсистема Windows Presentation Foundation (WPF)
393
393
программы Expression Blend над той же частью проекта, над которой работает разра ботчик (с помощью системы Visual Studio), и при этом избегать столкновения.
Благодаря гибкости языка XAML система WPF позволяет разрабатывать уникаль ные пользовательские интерфейсы и способы интерактивного взаимодействия (user ex periences). В их основе лежат стили и шаблонные функциональные возможности сис темы WPF, которая отделяет внешний вид элементов управления от их поведения.
Это позволяет легко изменять внешний вид элементов управления без изменения са мого элемента.
Хорошая новость заключается в том, что благодаря применению языка XAML техно логия WPF реализует лучший способ определения пользовательских интерфейсов по сравнению с Windows Forms, а также порождает большое количество дополнительных понятий. Плохая новость состоит в том, что эта гибкость и мощь языка XAML требует зна чительного времени для обучения даже опытных разработчиков. У разработчиков, дос тигших приемлемого уровня производительности труда с помощью технологии Windows
Forms, система WPF несомненно вызовет чувство неудовлетворения, пока они не освоят новые концепции и не испытают реальной потребности изменить свой образ мышления.
Многие простые задачи вначале выглядят намного более сложными, чем они могли бы быть, если их реализовать с помощью технологии Windows Forms. Однако со временем разработчики оценят преимущества новых возможностей, которые им предоставляют технология WPF и язык XAML. Поскольку графическая система Silverlight имеет много общего с системой WPF (обе основаны на языке XAML, так что Silverlight, по существу, —
это подсистема системы WPF), изучение технологии WPF позволит разработчиками одно временно научиться создавать приложения с помощью системы Silverlight.
Если читатели уже знакомы с более ранними версиями системы WPF
(поставляемыми с платформами .NET Framework 3.0 и 3.5), то они могли заметить, что текст, прорисованный в системе WPF, часто выглядел слегка расплывчатым, а не четким и контрастным. Это приводило к многочис ленным жалобам разработчиков. К счастью, в версии .NET Framework 4.0
прорисовка текста была значительно улучшена, и теперь разочарованные разработчики могут вернуться к использованию этой технологии. Компа ния Microsoft продемонстрировала свою приверженность технологии
WPF, переписав с ее помощью редактор кода в среде Visual Studio 2010,
чтобы показать ее мощь и гибкость.
Начало работы с системой WPF
Открыв диалоговое окно
New Project
, разработчик видит множество встроенных шаблонов проектов для технологии WPF, поставляемых вместе с системой Visual Stu dio 2010:
WPF Application
,
WPF Browser Application
,
WPF Custom Control Library и
WPF User Control Library
(рис. 18.1).
Обратите внимание на то, что эти проекты большей частью являются эквивален тами проектов для графической системы Windows Forms. Исключением является шаблон
WPF Browser Application
, генерирующий XBAP файл, использующий браузер как контейнер для пользовательского приложения “толстого” клиента (это похоже на то, что делает программа Silverlight, за исключением того, что XBAP приложение предназначено для полноценной платформы .NET Framework, которая должна быть инсталлирована на компьютере клиента).
Стр. 393
Стр. 393

394
Часть IV. Расширенные клиентские приложения
394
Рис. 18.1
В качестве примера создадим проект, используя шаблон
WPF Application
, хотя большинство функциональных возможностей системы Visual Studio 2010, обсуждае мых здесь, в одинаковой степени относится и к другим типам проектов. Генерируемая структура проекта выглядит так, как показано на рис. 18.2.
Рис. 18.2
Здесь видно, что структура проекта состоит из файлов
App.xaml и
MainWindow.
xaml
, каждому из которых соответствует свой исходный файл (
.cs или
.vb
), которые можно увидеть, развернув соответствующие узлы проекта. На этом этапе файл
App.xaml
Стр. 394
Стр. 394

Глава 18. Подсистема Windows Presentation Foundation (WPF)
395
395
содержит элемент
Application XAML
, имеющий атрибут
StartupUri
, который использует ся для определения первоначального загружаемого XAML файла (по умолчанию —
MainWindow.xaml
). В технологии Windows Forms он соответствует начальной форме.
Итак, если мы захотим изменить имена файла
MainWindow.xaml и его соответствующего класса на более информативные, то должны будем выполнить следующие действия.
Изменить имя файла с расширением
.xaml
. Исходный файл будет переимено ван автоматически и согласованно.
Изменить имя класса в исходном файле вместе с именем конструктора, а также зна чение атрибута x:Class элемента
Window в файле с расширением
.xaml
, для того,
чтобы сослаться на новое имя класса (полностью квалифицированное своим про странством имен). Обратите внимание на то, что два последних этапа выполняются автоматически, если сначала изменить имя класса в исходном файле и использовать интеллектуальные дескрипторы, которые появляются после этого, для того, чтобы переименовать объект во всех местах, где на него есть ссылки.
Изменить атрибут
StartupUri элемента
Application в файле
App.xaml и указать новое имя файла с расширением
.xaml
(поскольку он является объектом запуска).
Как видим, для переименования файла в WPF проекте требуется внести больше изменений, чем в стандартном проекте
Windows Forms
, однако эти изменения вполне очевидны, если вы знаете, что делаете (и используете интеллектуальные дескрипто ры, чтобы уменьшить количество требуемых действий).
Изучая окна системы Visual Studio на рис. 18.2, можно увидеть, что уже известное нам инструментальное окно
Toolbox
, расположенное вдоль левого края экрана, содер жит элементы управления WPF, похожие на элементы управления, которые использу ются при создании приложений по технологии Windows Forms. Под этим окном, все там же слева, расположено инструментальное окно
Document Outline
. И в проектах
Windows
Forms
, и в проектах
Web Applications оно содержит иерархическое представление эле ментов текущего окна. Выбрав один из этих узлов, можно выделить соответствующий элемент управления в основном окне редактора. Это упрощает навигацию по более сложным документам. Интересной особенностью окна
Document Outline при работе с системой WPF является тот факт, что если курсор мыши “зависает” над элементом, то пользователь может увидеть его миниатюрное изображение. Это помогает идентифи цировать выбираемый элемент управления.
Инструментальное окно
Document Outline можно свернуть у одного из кра ев рабочей области Visual Studio. И наоборот, его можно открыть, выбрав команду
View Other Windows
На рис. 18.2, справа, показано инструментальное окно
Properties
. И внешним ви дом, и функционированием оно очень похоже на инструментальное окно
Properties в
конструкторе форм в системе Windows Forms. Однако на самом деле это окно отно сится к конструктору системы WPF и имеет дополнительные возможности для редак тирования окон и элементов управления в этой графической системе. Посередине экрана расположена основная область редактирования и предварительного просмот ра, которая в данный момент разделена, чтобы продемонстрировать как визуальный макет окна (в верхней части), так и код на языке XAML, который этот макет опреде ляет (в нижней части).
Стр. 395
Стр. 395

396
Часть IV. Расширенные клиентские приложения
396
Основы языка XAML
Если читатели знакомы с языком XML (или хотя бы с языком HTML), то они заме тят, что синтаксис языка XAML относительно прост, поскольку он основан на языке
XML. Язык XAML имеет только один корневой узел, и элементы вкладываются один в другой, определяя внешний вид и содержимое пользовательского интерфейса. Каж дому элементу языка XAML соответствует класс платформы .NET, а именам атрибу тов — свойства/события этого класса. Отметим, что имена элементов и атрибутов чувствительны к регистру.
Посмотрим на XAML файл, по умолчанию созданный для класса
MainWindow
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" Height="300" Width="300">



Здесь
Window
— корневой узел, а
Grid
— элемент, который в нем содержится. Для то го чтобы понять их смысл, следует поразмышлять о них в терминах “окна, содержащего сетку”. Корневому узлу соответствует класс, определенный атрибутом x:Class и содержащий объявления префиксов пространств имен (вскоре мы вернемся к этой теме), а также некоторые атрибуты, используемые для задания значений свойств
(
Title
,
Height и
Width
) класса
Window
. Значения всех атрибутов (независимо от типа)
должны быть заключены в кавычки.
В корневом узле определены два префикса пространств имен. Оба эти префикса объявлены с помощью атрибута xmlns
(XML атрибута, используемого для объявления пространств имен). Объявления префиксов пространств имен в языке XAML можно рассматривать как аналоги инструкций using/Imports в начале классов в языках C#/VB, но без кавычек.
Эти объявления присваивают пространствам имен уникальные префиксы, исполь зуемые в XAML файле, а также префиксы, используемые для квалификации про странств имен при ссылке на классы, находящиеся в них (т.е. для задания местоположе ния классов). Префиксы сокращают многословность языка XAML, позволяя при ссылке на класс в файле XAML указывать только префикс, а не все пространство имен. Пре фикс определяется сразу после двоеточия в выражении xmlns
. Первое определение на самом деле не задает префикс, потому что оно определяет пространство имен, заданное по умолчанию (пространство имен системы WPF). В то же время второе объявление за дает x
как префикс пространства имен языка XAML. Оба определения отображаются в унифицированные идентификаторы ресурса URI, а не в конкретные пространства имен, поскольку они представляют собой консолидированные пространства имен
(т.е. охватывают несколько пространств имен) и поэтому ссылаются на единый иденти фикатор URI, используемый для определения данной консолидации. Однако разработчи ку не следует беспокоиться об этом — нужно просто оставить эти определения как есть и добавлять свои определения после них. Собственные определения пространств имен, до бавляемые разработчиком, почти всегда начинаются с ключевого слова clr-namespace
,
которое ссылается на пространство имен
CLR
и содержащую его сборку. Рассмотрим пример.
xmlns:wpf="clr-namespace:Microsoft.Windows.Controls;assemblty=WPFToolkit"
Стр. 396
Стр. 396

Глава 18. Подсистема Windows Presentation Foundation (WPF)
397
397
Префиксы могут быть любыми, но лучше всего делать их по возможности корот кими. Как правило, пространства имен определяются в корневом узле XAML файла.
Это не обязательно, поскольку префикс пространства имен может быть определен на любом уровне в XAML файле. И все же стандартной практикой стало собирать пре фиксы вместе в корневом узле, чтобы за ними было легче следить.
При необходимости сослаться на элемент управления в коде или связать его с дру гим элементом управления в XAML файле (например, при связывании элемента
Ele- mentName
) нужно приписать этому элементу управления какое то имя. Многие эле менты управления используют для этой цели свойство
Name
, но присвоить имя эле менту управления можно с помощью атрибута x:Name
. Он определен в пространстве имен XAML (поэтому имеет префикс x:
) и может применяться к любому элементу управления. Если свойство
Name реализовано (чаще всего так и есть, потому что это свойство определено в базовых классах, которые наследуются большинством элемен тов управления), этот атрибут просто отображается в него и служит той же цели. Рас смотрим пример. Инструкция

398
Часть IV. Расширенные клиентские приложения
398
любой элемент системы WPF. Это открывает практически безграничные возможно сти для настройки существующих элементов управления и освобождает пользователя от необходимости создавать свои собственные элементы управления. При разработке сложных пользовательских интерфейсов это очень полезно. Кроме того, многие эле менты управления больше не имеют удобных свойств, которые существовали в систе ме Windows Forms. Это может показаться несколько странным. Например, у элемента управления
Button в системе WPF нет свойства
Image
, позволявшего присваивать кнопке определенное изображение, как это было в системе Windows Forms. На пер вый взгляд, это сильно ограничивает возможности системы WPF, но это впечатление ошибочно, поскольку теперь у кнопки есть свойство
Content
. Так как свойство
Content позволяет присваивать элементу управления системы WPF определенное содержи мое, пользователь может присвоить ему элемент
StackPanel
(который будет рассмот рен в следующем разделе), содержащий как элемент управления
Image
, так и элемент управления
TextBlock
, обеспечивающие тот же самый эффект. Это требует от пользо вателя чуть больше усилий, чем при работе с системой Windows Forms, но позволяет ему проще моделировать содержимое кнопки на любой форме (а не подбирать эле менты управления, которые он может реализовать) и обеспечивает невероятную гиб кость системы WPF и языка XAML. Код на языке XAML для кнопки, показанной на рис. 18.3, имеет следующий вид.

Другими замечательными свойствами, которые отличаются от свойств системы Windows Forms, являются свойства
IsEnabled
(которое в системе
Windows Forms называлось
Enabled
) и
Visibility
(которое в системе Win dows Forms называлось
Visible
). На примере свойства
IsEnabled видно,
что имена большинства булевых свойств имеют префикс
Is
(например,
Is-
TabStop
,
IsHitTestVisible и т.д.), что соответствует стандартной схеме именования.
Однако свойство
Visibility больше не имеет булевого значения — теперь оно представ ляет собой перечисление, принимающее значение
Visible
,
Hidden или
Collapsed
Не забывайте о пакете WPF Toolkit, доступном на веб сайте http://wpf.
codeplex.com
, поскольку в него постоянно включаются новые элементы управления для системы WPF, которые могут оказаться полезными.
Компоновочные элементы управления в системе WPF
В системе Windows Forms для размещения элементов управления на рабочей по верхности использовались абсолютные координаты (т.е. каждый элемент управления имел явно заданные координаты x и y). Со временем появились элементы управления
TableLayoutPanel и
FlowLayoutPanel
, которые могут содержать другие элементы управления. Это позволило создавать более сложные схемы размещения элементов
Рис. 18.3
Стр. 398
Стр. 398

Глава 18. Подсистема Windows Presentation Foundation (WPF)
399
399
управления на форме. Однако концепция позиционирования элементов управления в системе WPF немного отличается от системы Windows Forms. Наряду с элементами управления, имеющими специальное предназначение (например, кнопками, полями ввода и т.п.), в системе WPF есть множество элементов управления, используемых специально для определения компоновки пользовательского интерфейса.
Компоновочные элементы управления являются невидимыми и предназначены для позиционирования других элементов управления на своей поверхности. В системе WPF
нет поверхности, по умолчанию предназначенной для позиционирования элементов управления, — поверхность, на которой работает пользователь, определяется компоно вочными элементами управления, образующими иерархию. Компоновочные элементы управления, как правило, находятся в этой иерархии непосредственно под корневым узлом XAML файла и определяют метод компоновки, принятый по умолчанию для дан ного XAML файла. Наиболее важными компоновочными элементами управления в систе ме WPF являются
Grid
,
Canvas и
StackPanel
, поэтому мы рассмотрим каждый из них. На пример, в XAML файле, созданном по умолчанию для класса
MainWindow
, рассмотренного ранее, элемент
Grid располагался непосредственно под корневым узлом
Window
, а значит,
должен был по умолчанию служить для этого окна рабочей поверхностью. Разумеется,
пользователь может заменить любой компоновочный элемент управления, а также ис пользовать любые дополнительные элементы управления для создания дополнительных поверхностей и иного размещения элементов управления.
В следующем разделе мы рассмотрим, как скомпоновать форму с помощью рабо чей поверхности конструктора, но сначала заглянем в код XAML, чтобы увидеть, как используются элементы управления.
Если пользователь хочет размещать элементы управления, используя абсолютную систему координат (как в системе Windows Forms), то он может в качестве поверхно сти выбрать элемент управления
Canvas
, предусмотренный в системе WPF.
Определение элемента
Canvas в языке XAML выглядит очень просто.


Для того чтобы разместить элемент управления (например,
TextBox
) на этой по верхности, используя координаты x и y (по отношению к левому верхнему углу эле мента
Canvas
), необходимо использовать концепцию присоединенных свойств (attached properties), принятую в языке XAML. Элемент управления
TextBox на самом деле не имеет свойств, определяющих его местоположение, поскольку его позиция в компо новочном элементе управления полностью зависит от типа этого элемента. Следова тельно, свойства, которых недостает элементу управления
TextBox
, чтобы определить его положение в компоновочном элементе, должны быть позаимствованы у самого компоновочного элемента, поскольку именно он определяет, где в нем должен нахо диться элемент
TextBox
. Именно в этот момент на первый план выходят присоеди ненные свойства. Коротко говоря, присоединенными называют свойства, которые присваивают элементу управления какое то значение, но определяются и принадле жат другому элементу управления, стоящему выше в иерархии элементов. При ис пользовании такого свойства его имя уточняется именем элемента управления, в ко тором оно на самом деле определено, за которым следует точка, а затем имя элемента управления, в котором оно используется (например,
Canvas.Left
). Присвоив это зна чение другому элементу управления, который содержится внутри (как, например, на ше поле ввода
TextBox
), элемент
Canvas хранит это значение в себе и с его помощью управляет позицией поля ввода. Например, следующий фрагмент кода на языке тре
Стр. 399
Стр. 399

400
Часть IV. Расширенные клиентские приложения
400
бует разместить поле ввода в точке 15, 10, используя свойства
Left и
Top
, определен ные в элементе управления
Canvas



В то время как абсолютное позиционирование в системе Windows Forms принято по умолчанию, в системе WPF для компоновки лучше всего использовать элемент управления
Grid
. Элемент управления
Canvas следует использовать редко и только при крайней необходимости, поскольку элемент управления
Grid представляет собой намного более мощное средство для определения компоновки форм и лучше работает в большинстве сценариев. Одним из самых заметных преимуществ элемента управле ния
Grid является возможность автоматически изменять размер его содержимого при изменении его собственного размера. Поэтому пользователь может легко проектиро вать формы, автоматически изменяющие свои размеры, чтобы заполнить всю доступ ную область,
— иначе говоря, размер и положение элементов управления в этой форме определяются динамически. Элемент управления
Grid позволяет разде лять свою область на подобласти (ячейки), в которые можно поместить другие эле менты управления. Эти ячейки определяются путем задания строк и столбцов сетки с помощью значений свойств
RowDefinitions и
ColumnDefinitions
. Пересечения строк и столбцов становятся ячейками, в которые можно помещать элементы управления.
Для определения строк и столбцов пользователь должен знать только, как определять сложные значения в языке XAML. До сих пор мы могли присваивать элементам управле ния лишь простые значения, которые отображались либо в элементарные типы данных платформы .NET, либо в имя элемента перечисления. Кроме того, мы могли конвертиро вать строку в соответствующий объект. Значения этих простых свойств использовались как атрибуты при определении элемента управления. Однако сложные значения нельзя присваивать таким способом, потому что они отображаются в объекты (т.е. необходимо выполнить присваивание нескольких свойство объекта) и должны определяться с помо щью синтаксиса “свойство–элемент” (property element syntax). Поскольку свойства
RowDefi- nitions и
ColumnDefinitions элемента
Grid представляют собой коллекции, они принимают сложные значения, которые должны быть определены с помощью синтаксиса “свойство–
элемент”. Например, рассмотрим сетку, состоящую из двух строк и трех столбцов, опреде ленных с помощью синтаксиса “свойство–элемент”.











Для того чтобы задать свойство
RowDefinitions с помощью синтаксиса “свойство–
элемент”, необходимо создать и определить дочерний элемент компонента
Grid
. Ставя имя
Grid перед именем свойства, мы указываем, что оно принадлежит элементу управ ления, который относится к более высокому уровню иерархии (как и в случае присое диненных свойств), а задание свойства в виде элемента XAML файла означает, что мы присваиваем сложное значение указанному свойству элемента управления
Grid
Свойство
RowDefinitions получает коллекцию объектов
RowDefinitions
. Таким об разом мы создаем несколько экземпляров объектов
RowDefinition
, образующих эту
Стр. 400
Стр. 400



Поделитесь с Вашими друзьями:
  1   2   3


База данных защищена авторским правом ©nethash.ru 2017
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал