Женя Золотько о WPF и разработке GUI вообще

Custom ListView Style, большой источник данных - вопросы производительности

2008-02-15T15:05:00Z

Я захотел сделать свой стиль для ListView - это не так сложно:

Но возникла проблема - в момент привязки сравнительно большого источника данных (5000 элементов) происходила значительная задержка (4 секунды); при использовании стандартного стиля все работало очень быстро.

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

Проблема состояла в том, что при использовании моего стиля ScrollViewer работал в режиме физического (то есть "попиксельного") скроллинга (CanContentScroll == false). Естественно, в этом режиме контейнеру нужно знать суммарную высоту содержимого - на эти измерения (строк) тратилось время при привязке, что и выяснилось при помощи профайлера.

Устанавливая CanContentScroll в true, мы включаем логический ("поэлементный") режим скроллинга. В таком режиме скроллинг происходит в "виртуальной" манере, и измеряется высота только видимых элементов - задержки нет. Заинтересовавшиеся этим вопросом могут исследвать интерфейс IScrollInfo.

Решение проблемы с нечеткими растрами в WPF

2008-02-03T13:47:00Z

Известно, что в текущей версии WPF существует проблема с качеством отображения растров. Возникает она из-за того, что WPF отображает визуальные элементы исходя из координат и размеров в логических единицах (долях дюйма) без точной привязки к пикселам. То есть, по умолчанию, растровое изображение в WPF-приложении будет иметь одинаковый размер в логических единицах на мониторе с разрешением 96 DPI и на супер-мониторе с разрешением 300 DPI. Теоретически это звучит хорошо, но на практике дело обстоит иначе.

Растровые изображения являются основным элементом пиксельной графики. Это означает, что эти избражения тесно связаны с пиксельной природой устройств, для использования на которых они предназначены. Точно также, как игра в «морской бой» связана с клетками на тетрадном листе. Таким образом, если начать играть в независимость пиксельных изображений от собственно пикселей, мы получим размытую картинку на мониторе. Что мы и имеем в современных WPF-приложениях.

На самом деле, есть случаи, когда такое положение вещей допустимо. Например, растянутая на фоне элемента управления текстура с размытыми цветами, и тому подобное. Но в большинстве случаев, когда растры используются для картинок в кнопках на панелях управления, меню (16х16, 32х32 пикселя), и так далее, это не годится; картинки размыты, приложение неумолимо теряет профессиональный вид.

Это не устраивает многих разработчиков, и обсуждение этой темы обычно заканчивается бессильными протестами в сторону создателей платформы. Но, к счастью, MSDN-блоггером было предложено решение этой проблемы. В статье описывается класс Bitmap, который позволяет отображать растры с точной пиксельной привязкой к целевому устройству. Используйте этот класс, и ваши растры будут вылядеть как родные! При этом, естественно на супер-мниторе с 300 DPI ваша картинка будет выглядеть крошечной. Но на то они и растры, я считаю. Примяняйте векторные изображения, и с масштабированием все будет отлично.

Прекрасно, но существует проблема, которая не позволяет использовать этот класс в случаях, когда нужно осущеcтвить привязку к данным через DataContext. Я столкнулся с этим при написании CellTemplate для ListView. Предполагалось, что ячейка будет содержать растровое избражение, привязанное к пикселам.

Но это, к сожалению, не работало. Возникало исключение, смысл которого в том, что наследование DataContext работает только для классов, производных от FrameworkElement. В то же время, наш американский товарищ унаследовал свой класс Bitmap от UIElement, потому что только так можно перекрыть методы, которые являются sealed для наследников FrameworkElement.

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

Чтобы проиллюстрировать все это, я сделал небольшой пример. В нем используется ListView для отображения всех файлов из папки System32 – имена и иконки 32х32. Обратите внимание, что иконки выглядят так же качественно, как в Explorer.

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

Компоненты .NET Framework 3.0 RTM доступны для скачивания

2006-11-07T08:02:00Z

Для тех, кто еще не знает:

Выпущена Release-to-manufacture версия .NET Framework 3.0; все ссылки здесь.

Как говорится в таких случаях, поехали! Делайте приложения, господа.

Задание значений свойств в XAML с использованием объединения флагов по ИЛИ

2006-11-03T05:00:00Z

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

Например,

// C#

MyType myObject = new MyType();

myObject.MyFlags = MyTypeFlags.Flag1 | MyTypeFlags.Flag2 | MyTypeFlags.Flag3;

// XAML

Как видите, здесь все просто. Вот только проблема в том, что разработчики не включили в документацию по WPF описание этой возможности. Для того, чтобы понять как это сделать, нужно обладать знаниями по работе метода Enum.Parse(), которые в общем выражаются следующим образом (текст из документации по Enum):

“You can use the static Parse method to initialize a Boolean type to the value of a string. This method accepts the enumeration type you are parsing, the string to parse, and an optional Boolean flag indicating whether or not the parse is case-sensitive. The string you are parsing can contain several values separated by commas, which can be preceded or followed by one or more empty spaces (also called white spaces). When the string contains multiple values, the value of the returned object is the value of all specified values combined with a bitwise OR operation.”

Таким образом, эта функциональность вообще не была специально реализована в WPF, а просто «наследуется» от базовой библиотеки типов. Видимо, поэтому это и не описано явно в документации по WPF, но хотелось бы, чтобы ситуация изменилась.

Мои доклады по WPF на Днях Разработчика 2006 в Украине

2006-10-30T21:04:00Z

На этой странице находится расписание осенних Дней Разработчика 2006 в Украине. Эти мероприятия будут проходить в Харкове, Донецке, Днепропетровске, Киеве, Львове, Одессе, Николаеве, Запорожье, Ровно, Виннице и Ивано-Франковске.

Я прочту доклады по WPF в Харкове, Львове, Одессе, Николаеве, Виннице, Ивано-Франковске.

Первое мероприятие в Симферополе уже успешно прошло, и я получил от него самые положительные впечатления. Так что рекомендую посетить, если у вас будет возможность.

Архитектура WPF. Dependency Properties

2006-10-18T15:17:00Z

Известно, что CLR дает возможность использовать в качестве членов классов свойства с параметрами или без. Например, в C# мы можем воспользоваться этим для создания get- и/или set- элементов для членов-данных и индексаторов с различным количеством параметров. Лаконичный синтаксис таких свойств весьма удобен и везде используется.

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

Иногда возникает необходимость наследования значений свойств в порядке отношений «родитель-ребенок» логического дерева. Например, если для родительской панели задан красный цвет фона, то такой цвет фона должны иметь и дочерние кнопки. Такая функциональность в разной степени реализована в Windows Forms и ActiveX (Ambient Properties); эти реализации довольно противоречивы, неполны и их практически невозможно использовать прикладному программисту.
Часто у клиентов какого-либо класса возникает потребность в отслеживании событий о изменении какого-либо свойства, не имея информации о конкретном свойстве (например, нужно отслеживать значение цвета фона, не имея сведений о наличии события BackColorChanged). Одним из способов достижения этого является использование стандартного интерфейса INotifyPropertyChanged, который находится в пространстве имен System.ComponentModel и содержит единственное событие PropertyChanged, аргументы которого включают имя измененного свойства в форме обычной строки.
Встречаются случаи, когда для реализации определенной подсистемы необходимы механизмы работы на метауровне наподобие Reflection, но очень быстрые. Тогда обычно применяются не очень-то элегантные решения типа Property Bags, сделанных на ассоциативных массивах и другие подобные вещи.

В качестве архитектурно целостного и элегантного решения этих и некоторых других проблем WPF вводит концепцию Dependency Properties (для себя я не нашел однозначно корректного перевода этого термина на русский язык, так что буду упоминать его в оригинале).

На базе Dependency Properties реализованы следующие подсистемы WPF:

Cтили
Data Binding
Наследование свойств в логическом дереве
Анимация свойств
Расширения разметки XAML
Layout визуальных элементов и другое

Dependency Properties можно рассматривать с двух точек зрения – как их использовать (на клиентской стороне), и как их создавать (на серверной стороне).

Для того, чтобы использовать такое свойство, вам не нужно учитывать практически ничего – для клиента оно выглядит как обычное CLR-свойство. То есть, пока вам в ваших классах не нужна функциональность, предоставляемая подсистемой Dependency Properties, вам не нужно знать об этом совсем ничего.

Для того, чтобы создать Dependency Property в своем коде, нужно знать и уметь определенные вещи. Использование Dependency Properties накладывает на дизайн вашего кода некоторые ограничения. Во-первых, класс, который содержит Dependency Property, должен быть наследником класса DependencyObject. Во-вторых, такие свойства создаются по определенному несложному шаблону. Идея этого шаблона состоит в том, чтобы сначала зарегистрировать описание вашего свойства, используя определенные статические методы классов среды, а затем предоставить доступ клиентам к этому свойству при помощи фасада из обычного CLR-свойства. Чтобы не путать вас таким описанием, приведу простой пример кода.

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

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

В заключение хочется подчеркнуть следующее. Далеко не все свойства в WPF – Dependency Properties. Этот механизм используется только там, где это нужно. Таким образом, для прикладного программиста должно стать естественным правило использовать Dependency Properties только при необходимости.

Архитектура WPF. Расширения XAML

2006-10-18T15:16:00Z

Описание значений свойств при помощи XAML-элементов

Значение свойства какого-либо объекта, описанного при помощи XAML, можно просто описать при помощи атрибутов XML, например:

Когда это требуется (например, если значение свойства является коллекцией элементов или содержит вложенные объекты, которые также подлежат описанию), программист может использовать другой синтаксис на базе XML-элементов. Например:

Здесь используются выражения типа “РодительскийЭлемент.ИмяСвойства”. Воспринимаются такие выражения довольно просто и натурально.

Похожий синтаксис используется для задания свойств, зависящих от родителя (аналог функциональности IExtenderProvider Windows Forms). Такие свойства называются Attached Properties и это тема для отдельного рассказа.

Расширения разметки XAML

Язык декларативной разметки XAML спроектирован как надмножество XML и предусматривает набор специфических для него расширений. В основном эти расширения заключаются в специальном синтаксисе, который формируется при помощи фигурных скобок {}. Такие расширения называются расширения разметки (Markup Extensions). Их использование выглядит следующим образом:

Здесь для значения свойства Style используется особый синтаксис, который указывает на необходимость получения значения из указанного ресурса. В XML-пространстве имен, которое обычно используется в WPF по умолчанию (http://schemas.microsoft.com/winfx/2006/xaml/presentation) имеется несколько типов таких расширений (например, StaticResource, DynamicResource, Binding, RelativeSource, TemplateBinding). Также в XML-пространстве имен, которое обычно объявляется под псевдонимом x (http://schemas.microsoft.com/winfx/2006/xaml) находятся несколько типов таких расширений (x:Type, x:Static, x:Null, x:Key). Используются они, естественно, точно также как и вышеупомянутые.

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

Программист может определить также свои расширения, реализовав соответствующий класс, порожденный от MarkupExtension.

Интересно ознакомится со справочником по доступным стандартным расширениям разметки XAML, который входит в состав документации по WPF. Таким образом можно узнать о многих интересных возможностях, например, встраивание в XAML процедурного кода при помощи x:Code.

Близкий взгляд на WPF. Часть 1. Знакомство с XAML

2006-10-18T15:09:00Z

Использование XAML(читается «замл») является основным способом декларативного программирования в среде WPF. Вот небольшой пример кода XAML, который используется для определения окна с текстом и кнопкой, визуально «прилепленными» к друг другу.

На рисунке показаны основные элементы этого простого примера. Весь документ занимает тэг Window, который декларативно определяет окно, его свойства и содержимое. Атрибут (1) задает имя так называемого Code-behind класса, то есть класса, который будет содержать процедурную программную логику для данной разметки. Понятие Code-behind классов позаимствовано из ASP.NET, где оно имеет практически ту же семантику и широко используется. Code-behind класс для данной разметки мы рассмотрим здесь чуть позже.

Атрибуты (2) содержат описания того, какие XML-пространства имен используются в данном документе. Те два пространства имен, которые мы видим на рисунке, используются в WPF практически всегда; их использование учтено в шаблонах для создания соответствующих элементов проектов Visual Studio. Первое пространство имен содержит описание стандартных элементов WPF и используется по-умолчанию, второе – описание специальных расширений XAML и по соглашению имеет псевдоним x. Также XAML предлагает специальный синтаксис для подключения пространств имен .NET; это выглядит следующим образом:

Как видно, для того, чтобы подключить CLR-пространство имен к вашему документу, необходимо назначить ему псевдоним, указать собственно его имя и имя сборки. Насколько я знаю, для того чтобы это работало, ссылка на эту сборку должна быть добавлена в проект. Для того чтобы добавить ссылку на пространство имен из текущей сборки, нужно просто опустить часть «;assembly=XXX».

Атрибуты (3) содержат описание некоторых свойств окна; здесь это заголовок, ширина и высота. Здесь все довольно просто.

Далее находятся тэги, которые описывают содержимое окна. Непосредственным логическим «ребенком» окна является панель типа StackPanel (4), которая используется для обеспечения последовательного горизонтального (как в данном случае) или вертикального размещения дочерних элементов.

В эту панель вложены два стандартных элемента управления: текстовый блок (5) и кнопка (6). Описание кнопки задает ее имя (которое будет доступно как имя члена класса типа Button из Code-behind класса) и подразумевает наличие обработчика события Click (7) также в этом процедурно описанном классе.

Прежде чем мы перейдем к рассмотрению code-behind класса, хочу сказать, что мне очень нравится возможность задавать имена только для тех элементов, для которых они нужны (как в случае с кнопкой). Известно, что в Windows Forms ситуация сложилась по другому – даже для самого незначительных сплиттера и панели нужно задавать имена и чаще всего они имеют вид вроде splitter1; затем, как показывает практика, разработчики привыкают к этому и начинают давать такие «безымянные» имена даже значимым элементам. Здесь же легко применить всегда полезный принцип – если надо что-то назвать – подумай и назови хорошо, а если не надо – то и не беспокойся.

На рисунке выше показан вид code-behind класса для описанной разметки. Выглядит очень похоже на описание такого же класса для Windows Forms – все очень просто. Впрочем, так и должно быть.

Кстати, у нас есть возможность выразить то, что мы сделали при помощи XAML, на C#. Если посмотреть на такой код (он будет похож на сериализованный код дизайнера Windows Forms), то он будет в полтора-два раза объемнее чем XAML, а элегантность и лаконичность не стоит даже и сравнивать.

Введение в WPF, часть 2

2006-10-18T15:08:00Z

Что нового? Основные факты.

Векторный принцип воспроизведения изображения на экране. Доступно также воспроизведение трехмерных сцен и отображение растров. Для формирования изображенния на экране используется так называемый graphics retained mode. То есть изображение на экране формируется не при помощи процедурной раскраски пикселов в методах типа OnPaint, а при помощи обработки движком среды данных о векторных и трехмерных примитивах в памяти. Такой подход очень похож на тот, который используется в программировании интерактивной трехмерной графики: прикладной программист задает систему вложенных графических объектов в памяти декларативным или процедурным способом, а графический конвейер производит растеризацию, то есть отображает то, что видно через камеру на экране. Следует учесть, что растеризация производится при помощи Direct3D, то есть с использованием доступных в системе средств аппаратного графического ускорения. Так как все элементы управления созданы методом композиции векторных графических примитивов, то становятся легко реализуемыми интересные эффекты масштабирования и свободных векторных трансформаций отдельных элементов управления, различных группирующих панелей и целых рабочих пространств.

Приложения на базе WPF делятся для две целевые группы – традиционные настольные и Web-based. Web-based отличаются от первых более низкими доступными привилегиями безопасности во время выполнения, отсутствием необходимости инсталляции приложения, и специальным странично-ориентированным (похожим на Web) механизмом навигации. Web-based приложения напоминают апплеты Java, но с отсутсвием заявлений со стороны Microsoft о их переносимости. Для запуска браузер-ориентированных приложений на целевой машине необходимо присутствие .NET Framework 3.0

Активное использование декларативных методов программирования. Разметка осуществляется при помощи использования формата XAML (Extensible Application Markup Language), спецификация которого является расширением спецификации XML. Использование XAML обусловлено несколькими причинами. Во-первых, есть смысл описывать при помощи XAML те вещи, для которых это является логичным и выгодным (например, разметка элементов управления, описание векторного и трехмерного графического материала, элементы data binding, и так далее). Выгоды от применения XAML в контексте средств разработки я опишу отдельным пунктом. После приобретения некоторого опыта работы со средой, способ мышления перестраивается на более «декларативный». Похожие вещи я наблюдал, когда начал активно применять шаблоны языка С++. Для создания WPF – приложения не обязательно использовать XAML. XAML является лишь верхним вспомогательным слоем управляемого API WPF. То есть к любой функциональности среды можно получить доступ процедурным способом.

XAML дает большие возможности для разработчиков инструментальных средств. Из-за наличия жесткой открытой спецификации формата XAML, сторонние разработчики могут создавать конкурирующие инструментальные средства (GUI Designers, Graphics Designers и т.д.). Уже сейчас на рынке имеются несколько таких коммерческих продуктов. Официальными инструментальными средствами для обработки XAML от Microsoft являются продукт под кодовым названием Orcas, который предоставляет функциональность GUI Designer в форме расширения для Visual Studio 2005 и системы под названием Expression Interactive Designer, которая является GUI Designer и Graphic Designer одновременно. Первый продукт предназначен для программистов, а второй в большей степени для графических дизайнеров соответственно. Примечательно то, что Expression Interactive Designer создан по технологии WPF и является функционирующим примером довольно большого приложения.

WPF предлагает разработчикам новую модель создания элементов управления. В отличие от «замкнутых в себе» элементов управления MFC и Windows Forms c прошитым внутри кодом пиксельной отрисовки, WPF предлагает элементы управления, созданные по принципам открытости и расширяемости. К любому стандартному элементу управления WPF можно применить стили и шаблоны. Стили являются некоторым аналогом CSS: они позволяют декларативно, централизованно, основываясь на типе целевого элемента, с учетом наследования, устанавливать значения различных свойств визуальных элементов. Шаблоны позволяют в значительной степени изменить стандартный внешний вид и поведение визуальных элементов декларативными способами.

Стандартная библиотека элементов управления содержит достаточный набор средств для организации GUI, но все же заметно, что Microsoft как обычно оставляет большую нишу на рынке для сторонних разработчиков библиотек элементов управления. Я думаю, что из-за вступления в силу новой архитектурной парадигмы для разработчиков элементов управления рынок сторонних библиотек для WPF будет качественно отличаться от подобных рынков для Windows Forms и MFC. Скорее всего, в эточ бизнесе большую роль приобретут графические дизайнеры.

Использование XAML, инструментальных средств, Retained mode graphics и механизмов расширения элементов управления дает возможность более структурировано организовать процесс разработки presentation layer приложений. Таким образом, дизайнер может «нарисовать» общий вид приложения при помощи XAML, а программист затем занимается несложной адаптацией такого макета к работающему приложению. Этим поток работ над оригинально выглядяшими приложениями WPF схож с деятельностью по разработке традиционных веб-сайтов (но с отсутсвием механических проблем с нарезкой, версткой и поддержкой переносимости).

Разработчики ввели в состав WPF достаточно обширную функциональность поддержки отображения и обработки различных документов. Теперь не нужно использовать ActiveX компонент веб-браузера или стандартный RichTextBox для отображения сложного отформатированного документа с разными встроенными объектами. Для этого в WPF существуют входящие в стандартную поставку элементы управления. В этом контексте Microsoft предлагает для использования новый универсальный основанный на XML формат XPS (XML Paper Specification). Кроме жестко специфицированного общего открытого формата документов (в замену достаточно ущербному на мой взгляд двоичному RTF и тяжеловесному PDF), спецификация XPS предоставляет возможности автоматической архивации и передачи таких документов, и продвинутую систему печати твердых копий, которая будет доступна в Windows Vista. Насколько я знаю, приложения из пакета Office 2007 могут экспортировать свои данные в формат XPS.

Существует так же встроенная поддержка анимации (изменения в зависимости от разных факторов) практически любых свойств визуальных объектов. Такая анимация может быть задана в XAML декларативно.

Хорошо поддерживаются встраиваемые в документы XAML (потоковые) видео и аудио данные.

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

Введение в WPF, часть 1

2006-10-18T15:04:00Z

Здравствуйте, меня зовут Женя Золотько и занимаюсь разработкой клиентских GUI-приложений и библиотек элементов управления последние несколько лет. Я успел поработать с несколькими разными средами создания GUI (включая не основанные на .NET). Сейчас близится выпуск .NET Framework 3.0, который включает в себя предложение Microsoft для разработчиков GUI - Windows Presentation Foundation (WPF, кодовое название Avalon). Я начал понемногу, обзороно и точечно изучать эту среду, и у меня возникло желание публиковать небольшие русскоязычные материалы по этой теме. Сейчас вы читаете первую такую публикацию.

Специфика разработки GUI-приложений.

Спустя некоторое время после того как разработчики начали создавать GUI-приложения в промышленных масштабах, некоторые из них стали задумываться о том, какие проблемы возникают и какие методы работы могут помочь в решении этих проблем. Оказалось, что проблем в этой области довольно много. Самой очевидной является то, что GUI-код на заре развития этой отрасли выглядел просто ужасно. Можно конечно возразить, что тогда были ковбойские времена и любой код выглядел ужасно. Но все же этот код был очень запутанным и чаще всего сами его создатели не могли в нем после разобраться. Далее, каждая компания-разработчик выдвигала свои требования к GUI-приложениям и добавляла свои "изюминки" к способу его реализации. Таким образом, для того, чтобы создавать морально допустимыми способами удовлетворительный UI, многие компании и разработчики создавали вспомогательные библиотеки практически с нуля. Позже выяснилось, что лушие способы создания GUI имеют похожие черты. Во-первых, чем лучше будет управление бизнес-логикой будет отделено от обработки ввода-вывода, тем лучше. Во-вторых, чем чаще код GUI повторно используется, тем лучше. И в третьих, чем проще задавать общий внешний вид для GUI тем тоже, естественно, лучше. И вот, исходя из этих и еще нескольких соображений, крупные и небольшие поставщики программного обеспечения (а конкретно библиотек и инструментов разработки) уже успели спроектировать, реализовать, научить людей пользоваться и продать довольно много разных решений, которые, по идее должны воплощать решение извечных проблем разработки GUI. Так уж выходит, что создать хорошее GUI-приложение без поддержки библиотек и сред разработки сейчас врядли получится.

Технологии-предшественники WPF, WinAPI и чистота концепций

Первая среда, с которой я столкнулся для разработки GUI была библиотка Turbo Vision, которая входила в состав пакета Borland Turbo Pascal. Эта среда позволяла создавать приложения, работающие под управлением MS-DOS в текстовом режиме работы экрана. Естественно, получающийся пользовательский интерфейс был не совсем графическим, но все равно довольно впечатляющим. Это была объектно-ориентированная библиотека на базе языка Turbo Pascal, которая к тому времени (почти два десятилетия назад) содержала почти все необходимые архитетурные элементы для современных промышленных решений. Она вводила понятия элементов управления, команд, событий или сообщений, и так далее. Расположение элементов управления надо было указывать процедурно вручную в координатах текстового экрана. Тогда она мне казалась верхом футуризма. Позже, когда Windows начала набирать обороты, появилась такая вещь, как WinAPI. При помощи нее Microsoft указывала способ, как писать программы (в том числе и GUI) для Windows. Все мы знаем о Common Controls, ресурсах, GDI и всех этих прекрасных инновациях Microsoft. Но еще, большей части здравомыслящих специалистов известно, что WinAPI - это своеобразное небольшое ИТ-средневековье. Почему-то все более или менее чистые концепции наработанные в "античные" времена DOS, сжигались на костре User32. Не очень-то много людей пострадало от "Ада DLL". Больше нормальных людей пострадало от ада венгерской нотации, моды на непонятные названия и непродуманные дизайнерские решения. Потом появилась MFC, со схожим по духу с WinAPI "объектно-ориентированным подходом", и компонентно-ориентированные продукты Borland, которые пытались построить более или менее концептуально чистые решения на базе неизбежного WinAPI. Еще все знают о до сих пор конвульсирующих элементах ActiveX, которые базируются на построенном на болоте здании COM. Потом появились идеи об управляемых средах, и они были реализованы в виде Java и .NET. Когда я узнал, что Microsoft делает свою управляемую платформу для Windows, я подумал, что они откажутся от WinAPI при создании стандартных библиотек. Но они почему-то создали GUI-библиотеку, очень похожую на библиотеки Borland Delphi/Bulder, только для управляемой среды - Windows Forms. Фактически, все то же, только в профиль. И только почти пять лет спустя Microsoft выпускает библиотеку, которая действительно тщательно спроектирована с нуля, содержит массу технологических инноваций и предлагает конечным пользователям GUI, основанный на новом векторно-трехмерном движке. Таким образом, некоторые из нас могут заинтересоваться этой действительно необычной ситуацией сейчас, и, возможно, получить от этого доход.

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