Главная » WPF » Элементы управления WPF

0

В главе 2 мы описали  порядок  создания  приложения, основные  компоненты пользовательского интерфейса, службы приложений и варианты их исполнения. Хотя интерфейс любого приложения состоит из окон, пользовательских элемен# тов и страниц, части, расположенные на верхнем уровне, строятся  из более мел# ких компонентов  – элементов  управления.

Сколько  существуют библиотеки  для построения  графических интерфейсов, столько же существуют и элементы управления. Называются ли они виджеты, гад& жеты, VBX, OCX, компоненты, CWnd, элементы или как#то по#другому, всегда при# сутствовала идея компонента,  инкапсулирующего некое поведение, объектную мо# дель и отображение.  Windows Presentation Foundation не является исключением.

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

Принципиальные основы элементов управления

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

В предшествующих каркасах одной из ключевых проблем было отсутствие последовательности и гибкости.  Для  создания  нестандартного списка  в Win32 приходилось пользоваться моделью программирования, которая в корне отлича# лась от модели использования элемента. В современных  версиях Windows кноп# ки в разных  местах реализованы совершенно  по#разному. Так, кнопки  в полосе прокрутки ведут себя иначе, чем кнопка закрытия окна, а та не похожа на станда# ртную кнопку  в диалоговом  окне. Команда,  разрабатывавшая WPF,  хотела соз# дать такую систему, в которой одна и та же кнопка могла бы использоваться пов# семестно. Поэтому в основу WPF был положен принцип композиции элементов.

Чтобы  интегрировать пользовательский интерфейс,  документы  и мультиме# диа, нам нужен был какой#то принцип  проектирования, охватывающий все слу# чаи употребления развитого содержимого. В ранних  версиях  HTML  допуска#

лось включать обогащенный  текст с разными шрифтами,  кеглями, цветами и плотностью  практически в любое место, за исключением  кнопки. Даже для того чтобы просто изменить цвет кнопки, приходилось создавать графическое изобра# жение. Win32  ушла немногим  дальше; единственным элементом,  в котором мог присутствовать обогащенный  текст, был RichEdit. Принцип развитого  содержи# мого говорит, что в любом месте, где допускается появление текста, должны под# держиваться обогащенный  текст, мультимедиа и другие элементы  управления.

Весь каркас .NET пронизан  одной идеей – упростить  модель программирова# ния. Этот же принцип мы применили и к элементам управления в WPF. Простая модель программирования – критически важная характеристики набора элемен# тов управления, которым разработчики могли бы пользоваться на практике.

Уже на ранних стадиях  работы над WPF возник  простой  (как  нам казалось) вопрос: какой должна быть объектная модель кнопки?  Нажимаемая кнопка – это один из самых распространенных элементов  управления; она существует в Windows,  начиная  с версии  1.0, а в Macintosh – начиная  с Mac OS 1.0. Без  нее просто никуда! Но тут команда WPF налетела на сук.

Рис. 3.1. Три принципа элементов управления: композиция, развитое содержимое и простая модель программирования

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

Button b = new Button(); Ellipse left = new Ellipse(); TextBlock text = new TextBlock(); text.Text = «Hello World»;

Ellipse right = new Ellipse();

b.Children.Add(left); b.Children.Add(text); b.Children.Add(right);

Неплохо,  но мы упустили  одну вещь. Что, если слово World во фразе  «Hello

World» должно быть выведено полужирным шрифтом?

Button b = new Button();

Ellipse left = new Ellipse(); TextBlock text = new TextBlock(); text.Inlines.Add(new Run(«Hello «)); text.Inlines.Add(new Bold(«World»)); Ellipse right = new Ellipse();

b.Children.Add(left); b.Children.Add(text); b.Children.Add(right);

Но  даже  если  нужно  что#то совсем  простое,  например  кнопка  с надписью

«OK», то код получится примерно  таким:

Button b = new Button(); Text text = new Text(); text.Text = «OK»;

b.Children.Add(text);

Сейчас вы должны  задаться  вопросом: что сталось с принципом  простой  мо# дели программирования? Ведь в действительности хотелось  бы, чтобы этот код выглядел  не сложнее чем:

Button b = new Button();

b.Text = «OK»;

Рис. 3.2. Надпись «Hello World» на кнопке

Здесь для добавления  содержимого  в кнопку хватило одного свойства, однако содержимое  может быть только  строкой.  А нам бы хотелось  поддержать  значи# тельно более сложное содержимое.

Вот мы и подошли к модели содержимого.

Модель содержимого

При  программировании на уровне  Win32  элементы  управления (например, ListBox,  Button и Label)  традиционно в качестве  данных содержат  строки. При проектировании WPF хотелось, с одной стороны, поддержать повсеместное при# сутствие развитого  содержимого,  а, с другой, отделить  данные от визуализации. Во многих системах  применяются сложные  способы разделения модели, вида и контроллера. При  этом требуется,  чтобы программист  понимал  модель  данных каждого  элемента  управления. Вместо  этого в WPF используется модель,  уже знакомая  многим разработчикам: система типов CLR.

Начнем с задания  содержимого  кнопки:

Button b = new Button();

b.Content = «Hello World»;

Здесь, как и следовало  ожидать, создается  простая  кнопка с надписью «Hello World» (рис. 3.2). Отметим,  что тип свойства  Content объекта Button – это System.Object, а не строка.

Рис. 3.3. Кнопка и составляющие ее элементы

Чтобы разобраться в происходящем, рассмотрим созданное изображение.  Мы знаем, что его корнем является кнопка, но где#то должно находиться  нечто, отоб# ражаемое как текст. Поскольку мы сторонники  композиции элементов, то для ри# сования  кнопки  воспользовались другими  элементами.  На рис. 3.3 показана  ие# рархия элементов, которая называется также деревом отображения.

Среди составных элементов  отображения на рис. 3.3 мы видим элемент ButtonChrome, который  отвечает  за вывод фона  кнопки  и еще два интересных элемента: ContentPresenter и TextBlock.  С элементом TextBlock  мы уже встреча# лись выше, этот класс выводит простой текст. Но что такое ContentPresenter?

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

По теме:

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