Это третья из восьми глав, посвященных взаимодействию пользователя c .NET Framework. Глава 31 была сосредоточена на таких темах, как отображение диалоговых окон, окон SDI и MDI, а также размещение различных элементов управления, в числе которых кнопки, текстовые поля и окна списков. В главе 32 мы рассматривали работу с данными в Windows Forms с применением различных элементов управления для отображения данных из самых разнообразных источников, которые могут встретиться в процессе разработки приложений.

Хотя все эти стандартные элементы управления достаточно мощны и адекватны для построения полноценного пользовательского интерфейса большинства приложений, все же бывают ситуации, когда может понадобиться дополнительная гибкость. Например, вам может потребоваться нарисовать текст в определенном шрифте в определенном, точно указанном месте окна, отобразить изображение без применения элемента управления PictureBox либо программно воспроизвести какие-то рисунки или другую графику. Стандартные элемента: управления, описанные в главе 31, ничего этого делать не позволяют. Чтобы отобразить такого рода вывод, приложение должно иметь возможность проинструктировать операционную систему о том, что должно быть отображено и в каком месте его окна.

А потому в данной главе мы изучим, как можно рисовать разнообразные элемент:, включая:

□ принципы рисования;

□ линии и простые контуры;

□ изображения BMP и другие графические файлы;

□ текст;

□ вопросы печати.

В процессе нам придется использовать множество вспомогательных объектов, включая перья (pens) для определения характеристик линий, кисти (brushes) для определения закраски областей и шрифты (fonts) для определения вида символов текста. Мы также углубимся в некоторые детали относительно того, как устройства интерпретируют и отображают различные цвета.

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

Основные принципы рисования

Этот раздел посвящен описанию основных принципов, которые необходимо понимать для того, чтобы приступить к рисованию на экране. Начнем его с общего обзора GDI - технологии, лежащей в основе GDI+, а также покажем, как связаны между собой GDI и GDI+. Затем рассмотрим несколько примеров.

GDI и GDI+

Вообще говоря, одной из сильных сторон Windows - да и всех современных операционных систем - является их способность абстрагироваться от деталей, характеризующих конкретные устройства, без указаний разработчика. Например, вам не нужно понимать работу драйвера устройства жесткого диска для того, чтобы программно читать или записывать файлы на диске. Вы просто вызываете соответствующие методы в соответствующих классах .NET (или во времена, предшествующие появлению .NET, - функции Windows API). Этот принцип также справедлив в отношении рисования. Когда компьютер рисует нечто на экране, он делает это путем отправки команд видеокарте. Однако на рынке присутствуют многие сотни разнообразных видеокарт, большинство из которых имеют отличный от других набор команд и возможностей. Если бы вам пришлось принимать это во внимание и писать специфический код для каждого видеодрайвера, то написание обычного приложения стало бы практически невозможной задачей. Вот почему, начиная с ранних версий Windows, появился интерфейс графических устройств (graphical device interface - GDI).

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

Как видим, объект контекста устройства (device context - DC; скоро мы рассмотрим его) - это очень мощный объект, и возможно, вас удивит, что под GDI все операции рисования должны выполняться через контекст устройства. DC используется даже в операциях, которые не требуют рисования на экране или любом другом аппаратном устройстве - таких как модификация графических изображений в памяти.

Хотя gDi предлагает относительно высокоуровневый программный интерфейс для разработчиков, он все же базируется на старом Windows API, с функциями в стиле C. GDI+ - это уровень, находящийся между GDI и приложением, которые предоставляет более интуитивно понятную, основанную на наследовании объектную модель. Хотя GDI+ - это в основном оболочка вокруг GDI, тем не менее, Microsoft посредством GDI+ предлагает ряд новых возможностей и увеличенную производительность по сравнению с некоторыми старыми средствами GDI.

Часть базовой библиотеки классов .NET, связанная с GDI+, огромна, и в этой главе мы лишь вкратце сможем коснуться основных ее возможностей, поскольку любая попытка раскрыть больше, чем крошечную часть библиотеки, превратила бы эту главу в огромное руководство, перечисляющее классы и методы. Гораздо важнее понять фундаментальные принципы, касающиеся рисования, чтобы вы смогли получить возможность при необходимости легко расширить свои знания. Полные списки всех классов и методов, доступных в GDI+, конечно же, содержатся в документации SDK.

Разработчикам на Visual Basic 6, скее всего, концепции рисования покажутся незнакомыми, потному что Visual Basic 6 сосредоточен на элементах управления, которсе выполняют рисование самостоятельно. Разработчики на C++/MFC, однако, окажутся на более знакомой территории, поскольку MFC требует от разработчиков более подробного управления процессом рисования с применением GDI. Однако даже если вы имеете обширный опыт работы с классическим GDI, все равно в этой главе найдете для себя много нового.

Пространства имен GDI+

В табл. 33.1 представлен обзор основных пространств имен, в которых находятся базовые классы GDI+.

Таблица 33.1. Основные пространства имен для базовых классов GDI+

Пространство имен Описание

System.Drawing Содержит большинство классов, структур, перечислений и делегатов,

обеспечивающих базовую функциональность рисования.

System.Drawing.Drawing2D Представляет основную поддержку для двумерной и векторной

графики, включая сглаживание, геометрические трансформации и графические пути.

System.Drawing.imaging Содержит различные классы, обеспечивающие манипуляции с графическими изображениями (битовые карты, файлы GIF и тому подобное).

System.Drawing.Printing Содержит классы, имеющие отношение к печати и предварительному просмотру выводимых на печать изображений.

System.Drawing.Design Включает некоторые предопределенные диалоговые окна, таблицы

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

System.Drawing.Text Включает классы для выполнения более сложных манипуляций со

шрифтами и семействами шрифтов.

Отметим, что почти все классы и структуры, использованные в этой главе, относятся к пространству имен System.Drawing.

Контексты устройств и объект Graphics

В GDI способ идентификации устройства, на которое нужно направить вывод, заключается в обращении к объекту, называемому контекстом устройства (device context - DC). DC сохраняет информацию об определенном устройстве и может транслировать вызовы функций программного интерфейса GDI в конкретные команды, направляемые устройствам. Вы также можете опросить контекст устройства на предмет того, какие возможности он предоставляет (например, может ли принтер печатать в цвете или же только в черно-белом изображении), дабы соответствующим образом откорректировать вывод. Если вы пытаетесь заставить устройство делать что-то такое, что оно не способно сделать, то DC обычно обнаруживает это и предпринимает