DRIVERVERSION

Версия драйвера. 0x0100 обозначает версию 1.0

HORZSIZE, VERTSIZE

размер устройства вывода в миллиметрах

HORZRES, VERTRES

размер устройства вывода в единицах устройства вывода (пикселях)

LOGPIXELSX,

LOGPIXELSY

число единиц устройства (пикселей), приходящееся на один логический дюйм¹

BITSPERPIXEL

число бит на 1 пиксель

PLANES

число битовых планов

Название атрибута

Стандартное значение

Установить

Получить

Mapping mode

Система координат

MM_TEXT

SetMapMode

GetMapMode

Window origin

Начало отсчета в логических координатах

0,0

SetWindowOrg 0

SetWindowOrgEx

OffsetWindowOrg 0

OffsetWindowOrgEx

GetWindowOrg 0

GetWindowOrgEx

Viewport origin

Начало отсчета в координатах устройства

0,0

SetViewportOrg 0

SetViewportOrgEx

OffsetViewportOrg 0

OffsetViewportOrgEx

GetViewportOrg 0

GetViewportOrgEx

Window extents

Масштабные коэффициенты системы координат

1,1

SetWindowExt 0

SetWindowExtEx

SetMapMode

ScaleWindowExt 0

ScaleWindowExtEx

GetWindowExt 0

GetWindowExtEx

Viewport extents

Масштабные коэффициенты системы координат

1,1

SetViewportExt 0

SetViewportExtEx

SetMapMode

ScaleViewportExt 0

ScaleViewportExtEx

GetViewportExt 0

GetViewportExtEx

Pen

Перо (карандаш)

BLACK_PEN

SelectObject

SelectPen 2

SelectObject

SelectPen 2

Current pen position

Текущая позиция пера

0,0

MoveTo 0

MoveToEx

LineTo

GetCurrentPosition 0

GetCurrentPositionEx

Brush

Кисть

WHITE_BRUSH

SelectObject

SelectBrush 2

SelectObject

SelectBrush 2

Brush origin

Начальная точка кисти

0,0 (screen)

SetBrushOrg 0

SetBrushOrgEx

GetBrushOrg 0

GetBrushOrgEx

Font

Шрифт

SYSTEM_FONT

SelectObject

SelectFont 2

SelectObjectSelectFont 2

Bitmap

Ассоциируемый битмап

отсутствует

SelectObject

SelectBitmap 2

SelectObject

SelectBitmap 2

Background mode

Режим заполнения фона

OPAQUE

SetBkMode

GetBkMode

Background color

Цвет фона

White

SetBkColor

GetBkColor

Text color

Цвет текста

BLACK

SetTextColor

GetTextColor

Drawing mode

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

Если вы в процессе рисования изменяли какие–либо атрибуты, то после того, как контекст был освобожден (удален) все ваши изменения теряются, а сразу после получения или создания контекста устройства все его атрибуты устанавливаются в стандартное состояние, приведенное в этой таблице. Из этого правила есть только одно исключение — если вы используете сохранение контекста устройства. Об этом — ниже.

Получение хендла контекста устройства

Как было отмечено выше, существует два метода получения контекста устройства — создание и получение контекста устройства. Разница связана с тем, что создание и, позже, уничтожение контекста устройства занимает некоторое время. Если вы собираетесь осуществлять вывод на принтер, то эти затраты времени ничтожно малы, по сравнению со всем временем печати. Однако, если вы собираетесь только осуществлять рисование в окне (которое может обновляться очень часто), то даже сравнительно быстрая операция создания контекста, повторенная многократно, займет значительное время. Поэтому в Windows существует несколько заранее созданных контекстов, соответствующих дисплею. При выводе в окно контекст создавать не надо, надо воспользоваться одной из функций, возвращающих такой заранее заготовленный контекст устройства.

Более того, в Windows методы, создающие контекст, предназначены для работы с устройством целиком, а методы, возвращающие уже существующий — с окном. Разница заключается в применении системы координат, связанной с контекстом. В первом случае система координат связана с верхним левым углом устройства, а во втором случае — с верхним левым углом внутренней (либо внешней) области окна.

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

Существует 7 основных методов получения и освобождения контекста устройства; причем каждый метод создает специфичный контекст устройства, предназначенный для выполнения определенных действий. Надо хорошо представлять, в каком случае каким методом надо пользоваться. Функции BeginPaint, GetDC, GetWindowDC возвращают заранее заготовленный контекст устройства, а функции CreateDC, CreateIC, CreateCompatibleDC и CreateMetaFile создают новый контекст.

1) При обработке сообщения WM_PAINT рекомендуется применять следующий способ:

PAINTSTRUCT ps;

BeginPaint (hWnd, &ps);

...

EndPaint (hWnd, &ps);

Структура PAINTSTRUCT содержит следующие данные:

typedef struct tagPAINTSTRUCT {

HDC hdc; // хендл контекста, он же возвращается функцией BeginPaint

BOOL fErase; // TRUE, если фон неверного прямоугольника надо очищать

RECT rcPaint; // неверный прямоугольник, может быть пустым!

// остальные поля используются Windows:

BOOL fRestore;

BOOL fIncUpdate;

BYTE rgbReserved[ 16 ];

} PAINTSTRUCT;

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

Начиная с Windows 3.x для задания областей, нуждающихся в перерисовке используются не неверные прямоугольники, а неверные области (region), которые могут быть сложной формы. В этом случае прямоугольник rcPaint может быть указан пустым, в то время как неверная область реально существует.

Кроме этого, функция BeginPaint выполняет еще несколько операций:

если fErase равен TRUE, тогда функция BeginPaint вызывает обработку сообщения WM_ERASEBKGND с параметрами wParam= hDC, lParam= 0

неверный прямоугольник маркируется верным. Для этого BeginPaint вызывает функцию ValidateRect.

Если вам надо обязательно рисовать на всем устройстве (окне), а не только в зоне неверного прямоугольника, то перед вызовом функции BeginPaint, вы можете маркировать нужный прямоугольник или область как нуждающуюся в перерисовке.

2) Иногда необходимо получить хендл контекста для всей внутренней области окна. Для этого вы можете воспользоваться следующим способом:

HDC hDC;

hDC = GetDC (hWnd);

...

ReleaseDC (hWnd, hDC);

Этот способ часто применяется для рисования во внутренней области окна при обработке иных сообщений, чем WM_PAINT. Если вы собираетесь использовать его при обработке сообщения WM_PAINT, то помните про:

восстановление фона окна (так как обычно это делает BeginPaint)

удалите неверные прямоугольники после рисования (так, например, вы можете вызвать ValidateRect (hWnd, NULL); для маркирования всего окна верным).

3) Еще реже приходится рисовать во внешней (неклиентной, non–client) части окна, тогда вы можете воспользоваться таким способом:

HDC hDC;

hDC = GetWindowDC (hWnd);

...

ReleaseDC (hWnd, hDC);

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

Интересная особенность этой функции — если в качестве хендла окна ей передать NULL, то функция возвратит хендл контекста, соответствующего всему дисплею.

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

HDC hDC;

hDC = CreateDC (lpszDriver, lpszDevice, lpszOutput, lpData);

...

DeleteDC (hDC);

Например, для рисования непосредственно на поверхности дисплея:

hDC = CreateDC ("DISPLAY", NULL, NULL, NULL);

или принтера:

hDC = CreateDC ("IBMGRX", "IBM Graphics", "LPT1:", NULL);

параметры имеют следующие значения:

Функция CreateDC применяется сравнительно редко, так как первоначально она была ориентирована на работу с устройствами типа принтера или плоттера. Однако, для применения этой функции надо было анализировать информацию об используемом принтере (ах), содержащуюся в файле win.ini. Начиная с Windows 3.x появились специальная библиотека, реализующая стандартные диалоги и наиболее распространенные действия, включая процесс получения контекста принтера. См., например, функцию ChoosePrinter.

5) Иногда получаемый контекст нужен только для того, что бы узнать характеристики устройства. Тогда создается несколько упрощенный, так называемый информационный контекст:

HDC hDC;

hDC = CreateIC (lpszDriver, lpszDevice, lpszOutput, lpData);

...

DeleteDC (hDC);

параметры функции такие же, как и в предыдущем случае.

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

6) Этот способ создает контекст так называемого совместимого устройства, оно реально не существует, но обладает характеристиками реально существующего.

HDC hCompatDC;

HDC hRealDC;

// для получения контекста реального устройства годится любой

// из способов 1..5

hRealDC= GetDC (hWnd);

// по хендлу контекста реально существующего устройства создается

// контекст совместимого устройства.

hCompatDC= CreateCompatibleDC (hRealDC);

// созданный таким образом совместимый контекст описывает устройство

// размером в 1 пиксел. Для нормальной работы с этим устройством

// его надо ассоциировать с битмапом, об этом - позже

// если контекст реального устройства нам больше не нужен, мы можем

// его освободить

ReleaseDC (hWnd, hRealDC);

// .. здесь мы можем использовать созданный совместимый контекст

// для освобождения совместимого контекста применяетсяфункция

DeleteDC (hCompatDC);

Совместимые контексты (compatible DC, memory DC) предназначены для работы с битмапами. Для этого созданный совместимый контекст ассоциируется с конкретным битмапом, после чего появляется возможность выполнять рисование на этом битмапе, либо осуществлять передачу изображения между битмапом и другим контекстом устройства. Подробнее о применении совместимых контекстов устройства см. в разделе «».

7) Последний способ создает так называемый метафайл. Это устройство только лишь запоминает команды GDI в специальном файле, а затем может воспроизвести заданное изображение на реальном устройстве, "проигрывая" запомненные команды. Контекст метафайла существенно отличается от других контекстов информацией об устройстве, так как ни к какому устройству он не привязан и не на кого не похож. Поэтому такие параметры, как число бит на пиксель, число встроенных шрифтов и пр. не имеет для него никакого смысла.

HDC hDC;

HANDLE hMF;

hDC = CreateMetaFile (lpszFilename);

...

hMF = CloseMetaFile (hDC);

...

DeleteMetaFile (hMF);

или

HDC hEnhDC;

HENHMETAFILE hEnhMF;

hEnhDC = CreateEnhMetaFile (lpszFilename);

...

hEnhMF = CloseEnhMetaFile (hDC);

...

DeleteEnhMetaFile (hEnhMF);

Как использовать полученный хендл метафайла мы рассмотрим позже.

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

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

Сохранение контекста устройства

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

Сохранение контекста может выполняться двумя существенно различающимися путями. Так, если вам надо для выполнения какого–то фрагмента рисунка изменить большое число атрибутов контекста, а для продолжения рисования их надо восстановить, то удобно воспользоваться парой функций SaveDC и RestoreDC для сохранения и восстановления контекста.

HDC SaveDC (hDC);

BOOL RestoreDC (hDC, hSavedDC);

Возможно специальное применение функции RestoreDC (hDC, -1) — восстановить в том виде, какой был перед последним вызовом SaveDC.

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

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

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

При работе с окнами, имеющими стиль CS_OWNDC удобно настраивать атрибуты контекста при создании окна, например так:

int PASCAL WinMain (HANDLE hInstance, HANDLE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow)

{WNDCLASS wc;

// при регистрации класса окна задать стиль CS_OWNDC:

wc.style= CS_OWNDC;...

RegisterClass (&wc);...}

// при обработке сообщений в оконной функции:

LRESULT WINAPI _export WinProc (HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)

{HDC hDC;

PAINTSTRUCT ps;

switch (wMsg) {

case WM_CREATE:...

hDC= GetDC (hWnd);

// ... установить атрибуты при создании окна

ReleaseDC (hWnd, hDC);...

break;

case WM_PAINT:

hDC= BeginPaint (hWnd, &ps);

// обычные функции получения хендла контекста устройства будут теперь

// возвращать хендл сохраненного контекста.

// здесь используются атрибуты, установленные ранее...

EndPaint (hWnd, &ps); // контекст по-прежнему должен быть освобожден

break;

case ...:...}

...}

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

В частном случае все окна одного класса могут иметь одинаковые атрибуты. Тогда можно указать стиль не CS_OWNDC, а CS_CLASSDC. Этот стиль указывает на то, что используется только одна сохраненная копия контекста в памяти, которая используется всеми окнами данного класса. В этом случае можно настраивать атрибуты контекста еще в функции WinMain, сразу после создания первого окна этого класса.

Системы координат GDI

Для начала надо уточнить то место, которое занимает система координат GDI в Windows. Как отмечалось при первом знакомстве, в Windows используется одновременно несколько разных систем координат. Среди них надо выделить следующие:

Система координат менеджера окон; в документации никак особо не оговаривается, что применяется именно эта система координат.

Система координат панели диалога; применяется только при разработке собственных диалогов. В тексте часто можно понять, что речь идет именно о ней, если оговаривается, что используются единицы диалога (dialog units). Если не оговаривается, то по контексту — все, связанное с шаблонами и ресурсами описания диалогов использует именно эту систему отсчета.

Система координат GDI; в документации координаты в системе координат GDI часто называют логическими координатами (logical coordinates). Там же может встретиться понятие координаты устройства (device coordinates).

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

Основные понятия

Вообще говоря, для задания любой системы координат необходимо как–то ее привязать к системе координат устройства (речь идет о системах координат, применяемых в Windows, а не о математическом понятии). Так, скажем, система координат менеджера окон отличается от системы координат устройства только лишь смещенным (а возможно и нет) началом отсчета — в верхний левый угол внутренней области окна.

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

В любом случае в Windows ту систему координат, по отношению к которой задается система координат GDI, называют системой координат устройства (device coordinates, viewport coordinates). А саму систему координат GDI называют логической системой координат (logical coordinates, window coordinates).

Обратите внимание, что английская терминология в этой области очень путаная, одно и то же понятие может обозначаться разными терминами даже в пределах одного абзаца. Так, термины viewport и device относятся к системе координат устройства, а термины logical и window описывают логическую систему координат. Это несколько странно, так как при выводе в окно система координат окна будет соответствовать координатам устройства, а логические координаты, используемые GDI, почему–то будут обозначаться термином window.

Когда система предоставляет вам контекст устройства, то его система координат совпадает с координатами устройства (окна), но у вас есть возможность эту систему координат самостоятельно изменить во время рисования на контексте.

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

В этих формулах используются нижние индексы в виде view и win, в соответствии с принятыми названиями атрибутов контекста устройства. Индекс view относится к системе координат устройства, а индекс win — к логической системе координат. То есть x_view и y_view — координаты какой–либо точки в системе координат устройства, X_view.org и Y_view.org— относительное смещение начал отсчета систем координат, выраженное в единицах устройства (viewport origin), X_win.org и Y_win.org — то же самое смещение, но выраженное в логических единицах (window origin), а X_view.ext, Y_view.ext и X_win.ext, Y_win.ext— масштабные коэффициенты (viewport extents, window extents).

Естественно, что в этих формулах смещение начала отсчета должно задаваться лишь единожды — либо для логической системы координат, либо для системы координат устройства. В каком именно виде — зависит исключительно от удобства. Например, если вы хотите начало отсчета логической системы координат поместить точно в центре окна (листа бумаги и пр.), то фактически вы знаете положение точки начала отсчета в координатах устройства — размеры контекста устройства, деленные пополам — тогда удобнее задать величины X_view.org и Y_view.org, а X_win.org и Y_win.org оставить равными нулю.

Рисунок 18. Система координат устройства и логическая система координат

Для обратного преобразования (из системы координат устройства в логическую систему координат), будут применяться такие же формулы, но с переставленными индексами win и view:

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

BOOL DPtoLP (hDC, lpPoints, nCount);

BOOL LPtoDP (hDC, lpPoints, nCount);

Функция DPtoLP преобразует координаты точек, заданных массивом lpPoints из nCount объектов типа POINT, заданные в системе координат устройства в логические координаты (DPtoLP — Device Point to Logical Point), то есть из «view» в «win», а функция LPtoDP — выполняет обратное преобразование.

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

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

POINT pt;

pt.x = 10; pt.y = 0;

DPtoLP (hdc, &pt, 1); // пересчитаем 10 пиксель (ед. устройства) в логические

// единицы. Далее считаем, что в компоненте pt.x записана нужная нам величина

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

Рисунок 18. Из–за смещения начала отсчета возможно возникновение ошибок.

Что бы избежать подобной ошибки лучше брать не одну точку, а вектор нужной длины:

POINT vector[ 2 ];

vector[0].x = 0; vector[0].y = 0;

vector[1].x = 10; vector[1].y = 0;

DPtoLP (hdc, &vector, 2);

vector[1].x -= vector[0].x;

// Далее считаем, что в компоненте vector[1].x записана нужная нам величина

Выбор системы координат

Для описания используемой системы координат предназначено пять атрибутов контекста устройства. Четыре атрибута описывают смещение начала отсчета и масштабные коэффициенты. Пятый атрибут — собственно выбранная в настоящий момент система координат.

Стандартная система координат GDI, выбираемая в контекст устройства при его создании совпадает с системой координат самого устройства (или окна). Такая система координат получила название текстовой (MM_TEXT). Вы можете отказаться от этой системы координат и установить некоторую собственную систему, у которой ориентация осей или масштабные коэффициенты отличаются от стандартной. Очевидно, что чаще всего придется устанавливать какие–либо системы координат, базирующиеся на метрической или английской системах мер. Раз так, то Microsoft предоставляет несколько дополнительных систем координат, так что во многих случаях вы можете просто выбрать подходящую вам метрическую (MM_LOMETRIC, MM_HIMETRIC), английскую систему (MM_LOENGLISH, MM_HIENGLISH) или полиграфическую (MM_TWIPS), не заботясь о точном вычислении масштабных коэффициентов. Более того, используя какую–либо из вышеназванных систем вы вообще не можете изменять масштабные коэффициенты, хотя можете перемещать точку начала отсчета.

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

Обратите внимание, что при выборе любой системы координат начало отсчета размещается в верхнем левом углу контекста, даже если ось Y направлена вверх (!). При этом получается, что весь рисунок располагается в области отрицательных значений координаты Y. На практике это значит, что для большинства систем координат (кроме MM_TEXT и MM_TWIPS) вы как правило должны задать новое положение начала отсчета.

Внимание! На 16^ти разрядных платформах координаты задаются целым 16^ти разрядным числом со знаком, так что минимальное значение -32768, а максимальное +32767.

Для того, что бы определить или изменить текущую систему координат можно воспользоваться функциями GetMapMode, которая возвращает индекс используемой системы координат, или SetMapMode, которая устанавливает новую систему координат:

UINT GetMapMode (hDC);

UINT SetMapMode (hDC, nIndex);

Функции, изменяющие положение точки начала отсчета и масштабные коэффициенты, возвращают информацию о предыдущих или ныне действующих значениях атрибутов различным образом. Существует некоторый «старый» набор функций, изначально ориентированный на 16^ти разрядную платформу. Эти функции возвращают обе компоненты атрибута (масштабные коэффициенты по осям X и Y), упакованные в двойное слово; младшее слово содержит компонент X, а старшее — компонент Y. Для получения этих компонент по отдельности можно воспользоваться макросами LOWORD (dw) и HIWORD (dw).

Так как в Win32 API координаты задаются целым числом, то есть 32^х разрядным, то упаковать два компонента в одно двойное 32^х разрядное слово стало невозможно. В связи с этим GDI предоставляет дополнительные функции, возвращающие необходимую информацию в структуре типа SIZE или POINT. По счастью, необходимые изменения были внесены в Windows API еще во времена Windows 3.1, так что использование большинства функций, типичных для Win32 API возможно и в Windows API.

При использовании любой стандартной системы координат вы можете самостоятельно установить положение начала отсчета логической системы координат, задав его либо в логических единицах (window origin), либо в единицах устройства (viewport origin) с помощью функций:

// Реализованы только в Windows API

DWORD GetWindowOrg (hDC); 0

DWORD GetViewportOrg (hDC); 0

DWORD SetWindowOrg (hDC, nX, nY); 0

DWORD SetViewportOrg (hDC, nX, nY); 0

// Реализованы в Windows API (начиная с Windows 3.1) и в Win32 API

BOOL GetWindowOrgEx (hDC, lpPoint);

BOOL GetViewportOrgEx (hDC, lpPoint);

BOOL SetWindowOrgEx (hDC, nX, nY, lpPrevPoint);

BOOL SetViewportOrgEx (hDC, nX, nY, lpPrevPoint);

Для задания масштабных коэффициентов вы можете воспользоваться функциями

// Реализованы только в Windows API

DWORD GetWindowExt (hDC); 0

DWORD GetViewportExt (hDC); 0

DWORD SetWindowExt (hDC, nX, nY); 0

DWORD SetViewportExt (hDC, nX, nY); 0

DWORD ScaleWindowExt (hDC, xMul, xDiv, yMul, yDiv); 0

DWORD ScaleViewportExt (hDC, xMul, xDiv, yMul, yDiv); 0

// Реализованы в Windows API (начиная с Windows 3.1) и в Win32 API

BOOL GetWindowExtEx (hDC, lpSize);

BOOL GetViewportExtEx (hDC, lpSize);

BOOL SetWindowExtEx (hDC, nX, nY, lpPrevSize);

BOOL SetViewportExtEx (hDC, nX, nY, lpPrevSize);

BOOL ScaleWindowExtEx (hDC, xMul, xDiv, yMul, yDiv, lpPrevSize);

BOOL ScaleViewportExtEx (hDC, xMul, xDiv, yMul, yDiv, lpPrevSize);

При использовании функций Scale...Ext... система осуществляет коррекцию масштабных коэффициентов с помощью следующих формул:

X_new.ext = (X_old.ext * xMul) / xDiv

Y_new.ext = (Y_old.ext * yMul) / yDix

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

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

Но можно сделать и проще — воспользоваться системой координат MM_ISOTROPIC. При установке атрибутов в такой системе координат GDI сам корректирует их значения, что бы обеспечить равную цену единиц. При этом важно устанавливать сначала масштабные коэффициенты логической системы координат (с помощью функции SetWindowExt или SetWindowExtEx) и только затем коэффициенты системы координат устройства (с помощью функции SetViewportExt или SetViewportExtEx).

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

Практические примеры

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

void Cls_OnPaint (HWND hwnd)

{PAINTSTRUCT ps;

RECT rc;

BeginPaint (hwnd, &ps);

// устанавливаем собственную систему координат

GetClientRect (hwnd, &rc); // rc.left и rc.top всегда равны 0

SetMapMode (ps.hdc, MM_ISOTROPIC);

// задаем масштабные коэффициенты

SetWindowExtEx (ps.hdc, 1000, 1000, (LPSIZE)0L);

SetViewportExtEx (ps.hdc, rc.right, -rc.bottom, (LPSIZE)0L);

// перемещаем начало отсчета в центр контекста

SetViewportOrgEx (ps.hdc, rc.right/2, rc.bottom/2, (LPPOINT)0L);

... // осуществляем рисование в выбранной системе координат

EndPaint (hwnd, &ps);}

В качестве другого примера обратим внимание на систему координат MM_TWIPS. В этой системе координат за единицу принята 1/1440 доля дюйма. Если при подготовке какого–либо полиграфического макета вы применяете эту систему координат для вывода на принтер, то может быть целесообразным при выводе на экран воспользоваться аналогичной системой, но базирующейся на логическом дюйме:

void Cls_OnPaint (HWND hwnd)

{PAINTSTRUCT ps;

BeginPaint (hwnd, &ps);

// устанавливаем собственную систему координат

SetMapMode (ps.hdc, MM_ANISOTROPIC);

SetWindowExtEx (ps.hdc, 1440, 1440, (LPSIZE)0L);

SetViewportExtEx (

ps.hdc,

GetDeviceCaps (ps.hdc, LOGPIXELSX),

GetDeviceCaps (ps.hdc, LOGPIXELSY),

(LPSIZE)0L);

... // осуществляем рисование в выбранной системе координат

EndPaint (hwnd, &ps);}

В других случаях может возникнуть необходимость изменить масштабные коэффициенты, отталкиваясь от какой–либо стандартной системы координат. Ну, к примеру, вам надо отобразить на экране чертеж какого–либо объекта, размеры которого заданы в метрической системе координат, но при этом отобразить его в необходимом масштабе. Например, чертеж микродвигателя удобно увеличить раз в 10, а чертеж автомобиля — уменьшить раз в 50. В то же время удобно сохранить прежнюю единую метрическую систему задания размеров. Для этого удобен следующий прием — установить сначала необходимую метрическую систему координат, затем переключиться в анизотропные (или изотропные) координаты и потом скорректировать масштабные коэффициенты.

void Cls_OnPaint (HWND hwnd)

{PAINTSTRUCT ps;

SIZE sz;

RECT rc;

BeginPaint (hwnd, &ps);

GetClientRect (hwnd, &rc);

// устанавливаем собственную систему координат

SetMapMode (ps.hdc, MM_HIMETRIC);

SetMapMode (ps.hdc, MM_ANISOTROPIC);

// рисовать будем автомобиль — масштаб 50:1

ScaleWindowExtEx (ps.hdc, 50,1, 50,1, &sz);

// перемещаем начало отсчета в нижний левый угол листа

SetViewportOrgEx (ps.hdc, 0, rc.bottom, (LPPOINT)0L);

... // осуществляем рисование в выбранной системе координат

EndPaint (hwnd, &ps);}

Этот–же прием может использоваться для «переворота» осей координат. Например, можно установить метрическую систему, но ось Y направить вниз, как в MM_TEXT.

Глобальные системы координат GDI (Win32 API)

Внимание! В данном разделе рассматриваются дополнительные возможности по преобразованию систем координат, поддерживаемые 32^х разрядными подсистемами в Windows NT. Остальные реализации Win32 API и все реализации Windows API не поддерживают этих возможностей.

В Win32 API предусмотрен альтернативный, более медленный, но существенно более мощный механизм для определения собственных систем координат. К сожалению, в документации при описании новых возможностей Win32 API в очередной раз произошла смена терминологии (английской). При рассмотрении глобальных систем координат выделяют четыре понятия:

система координат физического устройства (physical device coordinate space)

система координат устройства (device coordinate space)

логическая система координат (page coordinate space)

глобальная система координат (world coordinate space)

(Русскоязычная терминология приводится с минимальными изменениями по сравнению с предыдущим разделом, англоязычная — в соответствии с документацией).

Система координат физического устройства соответствует координатам и единицам устройства; для того, что бы можно было удобно работать с самыми различными устройством вводится система координат устройства, использующая какие–­либо независимые от устройства единицы отсчета — например, дюймы и миллиметры. Логическая система координат соответствует логическим координатам в понимании Windows API и на нее распространяются все рассмотренные в предыдущих разделах преобразования. Следующий уровень абстракции — глобальная система координат — добавляет дополнительный механизм пересчета координат, обеспечивающий возможность поворота, перекоса, отражения и масштабирования координат.

Все эти системы координат 2^х мерные, различаются только ориентацией осей, ценой деления и максимальным диапазоном изменения координат. Так координаты физического устройства ограничены, естественно, размерами самого устройства (или окна), координаты устройства могут изменяться в диапазоне 2²⁷ единиц как по горизонтали, так и по вертикали, а логические и глобальные координаты —в диапазоне ±2³¹ единиц.

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

x’ = M₁₁ * x + M₂₁ * y + D_x

y’ = M₁₂ * x + M₂₂ * y + D_y

Полученные в результате такого преобразования координаты x’ и y’ рассматриваются как логические и затем подвергаются преобразованию, соответствующему переходу от логической системы координат к координатам устройства (см. функцию SetMapMode).

Проверить, какой режим используется, или установить нужный вы можете с помощью функций

int GetGraphicsMode (hDC);

int SetGraphicsMode (hDC, nIndex);

Для задания индекса режима можно использовать одно из двух символических имен:

GM_COMPATIBLE — режим, используемый по умолчанию, соответствует обычному преобразованию логических координат в координаты устройства, принятому в Windows API.

GM_ADVANCED — расширенный режим Win32 API. В этом режиме вы можете определять или изменять матрицу преобразования глобальных координат. Точнее говоря, вы можете вызывать функции для задания или изменения матрицы преобразования координат. Если такая матрица уже задана и отличается от стандартной, то даже при переходе в GM_COMPATIBLE она будет использоваться по–прежнему. Для отключения преобразований вы должны установить стандартную матрицу преобразований (M₁₁ и M₂₂ равны 1.0, остальные коэффициенты M₂₁, M₁₂, D_x и D_y равны 0.0) с помощью функции SetWorldTransform, либо, воспользовавшись функцией ModifyWorldTransform установить исходную матрицу.

BOOL GetWorldTransform (hDC, lpxformMatrix);

BOOL SetWorldTransform (hDC, lpxformMatrix);

BOOL ModifyWorldTransform (hDC, lpxformMatrix, dwMode);

BOOL CombineTransform (lpxformResult, lpxformA, lpxformB);

typedef struct tagXFORM {

FLOAT eM11;

FLOAT eM12;

FLOAT eM21;

FLOAT eM22;

FLOAT eDx;

FLOAT eDy;

} XFORM;

Функция GetWorldTransform возвращает текущую матрицу преобразований, SetWorldTransform позволяет задать новую матрицу, а функции ModifyWorldTransform и CombineWorldTransfrom используются для изменения и вычисления коэффициентов матрицы. Считается, что матрица XFORM используется следующим образом:

В этой форме матрица XFORM сделана квадратной, добавлением третьего столбца с неизменяемыми значениями, равно как и вектора сделаны трехкомпонентными добавлением еще одного компонента, равного 1. Векторная форма записи этой матрицы будет полезна при рассмотрении функции ModifyWorldTransform, которая выполняет умножение текущей матрицы преобразований на заданную вами. Такое умножение может выполняться двумя способами (умножение матриц не коммутативно): если параметр dwMode равен MWT_LEFTMULTIPLY, то задаваемая вами матрица используется как левый операнд умножения, а текущая — как правый; а если dwMode равен MWT_RIGHTMULTIPLY, то задаваемая вами матрица будет располагаться справа от текущей. Еще одно возможное значение параметра dwMode — MWT_IDENTITY — устанавливает стандартную матрицу преобразований, при этом параметр lpxformMatrix не используется.

Последняя функция CombineTransform служит для вычисления новой матрицы преобразований lpxformResult по двум заданным матрицам lpxformA, lpxformB, которые рассматриваются как матрицы, задающие два последовательно выполняемых преобразования. Здесь интересно сделать обзор основных простейших преобразований систем координат и задаваемых для них коэффициентов. Это позволит любое сложное преобразование описать как последовательность примитивных действий и построить требуемую матрицу автоматически.

Перемещение (translation). Перемещение осуществляется добавлением постоянных величин к координатам x (коэффициент D_x) и y (коэффициент D_y). При этом коэффициенты M₁₁ и M₁₂ должны быть равны 1, а M₁₂ и M₂₁ равны 0. Формула в матричном виде раскрывается следующим образом:

Масштабирование (scaling) и зеркальное отражение (reflection). Обе эти операции выполняются одним способом, для их задания необходимо указать масштабные коэффициенты M₁₁ (масштаб по оси X) и M₂₂ (масштаб по оси Y).

Отрицательные значения коэффициентов соответствуют перевернутому виду. Для получения зеркального отражения задают коэффициенты равными -1.

`Поворот (rotation). Для задания коэффициентов необходимо узнать угол поворота a. Если он известен, то коэффициенты M₁₁ и M₂₂ оба будут равны cos a, коэффициент M₁₂ будет равен sin a, а коэффициент M₂₁ =  sin a. То есть для задания поворота необходимо вычислить коэффициенты M₁₁ и M₁₂, а коэффициенты M_{22 и} M₂₁ получаются из уже вычисленных: M₂₂ = M₁₁ и M₂₁ = -M₁₂.

Сдвиг (shear). Для задания сдвига (описание неперпендикулярных осей координат) необходимо задать два коэффициента M₁₂ и M₂₁, задающих величину сдвига осей. При этом коэффициенты M₁₁ и M₂₂ оба равны 1.

Внимание! Помимо возможности использовать функции для изменения матрицы преобразований режим GM_ADVANCED отличается от GM_COMPATIBLE рисованием прямоугольников и эллипсов — нижняя и правая границы в этом режиме включаются в рисуемый объект и рисованием дуг — они всегда рисуются против часовой стрелки.

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

Режим GM_ADVANCED отличается от GM_COMPATIBLE тем, что он позволяет изменять матрицу преобразований плюс включение нижней и правой границ ограничивающего прямоугольника в рисуемый объект, плюс рисование дуг всегда против часовой стрелки плюс некоторые особенности отображения растровых шрифтов. Сама матрица преобразований используется постоянно, вне зависимости от текущего режима, в то время как в режиме GM_COMPATIBLE вы ее просто не можете изменять. Переключение из расширенного режима в совместимый вовсе не запрещается и корректно выполняется системой.

Объекты GDI

При рассмотрении таблицы атрибутов контекста устройства вы наверное заметили, что значительное количество атрибутов изменяются с помощью функции SelectObject. Эти атрибуты представлены специальными структурами данных, описывающими так называемые объекты GDI. Эти объекты описывают некоторые примитивы GDI, используемые при выводе изображений. В качестве примера можно привести перья (pen) и кисти (brush), применяемые при рисовании линий и закраске фона фигур.

Объекты GDI не имеют ничего общего с объектами ООП, они являются объектами с только точки зрения Windows и принадлежат модулю GDI. Фактически такой объект реализован как специальная структура (иногда несколько структур) данных, управление которыми осуществляется системой, а вы можете этими данными манипулировать, используя хендл. Эти структуры данных не являются интерактивными и они не получают никаких сообщений. Так что использование в данном случае термина объект является не слишком удачным, хотя и общепринятым.

Общие правила

Объектов GDI существует достаточно большое количество, но все они имеют сходные правила применения. Перед тем как приступить к их использованию целесообразно рассмотреть основные правила применения объектов GDI.

1) Объекты могут создаваться и уничтожаться в любой момент времени, причем они могут сохраняться и между обработкой разных сообщений. Поэтому объекты часто создаются в функции WinMain или при обработке сообщения WM_CREATE, а уничтожаются, соответственно, либо при обработке сообщения WM_DESTROY, либо перед выходом из функции WinMain.

2) Все созданные объекты обязательно должны быть уничтожены до завершения приложения. Windows сам не уничтожает оставленных приложением объектов, что может привести к быстрому исчерпанию ресурсов. Это связано с тем, что объекты GDI размещаются не в глобальной памяти Windows, а в локальной памяти модуля GDI (USER.EXE или GDI32.EXE). Для этого модуля ограничен максимальный размер локальной кучи в 64К для 16^ти разрядных (Windows 3.x, Windows–95) и 4М для 32^х разрядных (Windows NT, Windows–98) графических подсистем, причем объекты GDI, созданные каким–либо приложением, с этим приложением не ассоциируются, в следствие чего автоматического уничтожения этих объектов не происходит³.

3) Перед уничтожением объекта вы должны быть уверены, что он не выбран контекст устройства. Если объект в момент уничтожения используется, то он не будет уничтожен.

4) Объекты GDI кэшируется системой. То есть повторное создание часто используемого объекта осуществляется существенно быстрее, чем в первый раз.

5) Помимо создаваемых в приложении объектов, система может вам предоставить некоторые стандартные, которые соответствуют наиболее часто применяемым объектам. Например — тонкое перо черного цвета или кисть белого цвета и т.д. Стандартные объекты нельзя уничтожать. Вообще–то система должна заметить, что предпринимается попытка уничтожения стандартного объекта и запретить эту операцию. Но ошибки встречаются везде, даже в системе, так что лучше не уповать на ее надежность.

6) Разные объекты имеют хендлы со специфичными названиями HPEN, HBRUSH, HFONT и др. Вы можете применять просто HANDLE или HGDIOBJ вместо всех этих типов. Применение специфичных типов может быть предпочтительным при осуществлении строгой проверки типов. В разных API и реализациях windows.h для разных компиляторов стандартные функции GDI могут использовать несколько различающиеся типы хендлов. Так, например, функция SelectObject, которая может работать с объектами разных типов, обычно декларирована как функция, получающая хендл типа HGDIOBJ. Однако в старых 16^ти разрядных версиях windows.h она может быть описана как получающая просто HANDLE. Часто может быть удобнее применять макросы, определенные в windowsx.h, которые осуществляют соответствующие операции с необходимым приведением типов. Например, вместо SelectObject можно использовать макросы SelectPen, SelectBrush, SelectFont и т.д., смотря по типу выбираемого объекта.

7) Стандартные объекты можно получить с помощью функции

HGDIOBJ GetStockObject (nIndex);

Она возвращает хендл стандартного объекта. Нужный объект задается параметром nIndex. Например, это может быть BLACK_PEN, WHITE_BRUSH, SYSTEM_FONT и т.д. Подробнее — см. в описании функции. Либо, вместо этой универсальной функции можно применять макросы, определенные в windowsx.h: GetStockPen, GetStockBrush, GetStockFont и пр. Эти макросы будут возвращать результат соответствующего типа (HPEN, HBRUSH, HFONT, ...). При использовании макросов надо проследить, что бы индекс требуемого объекта соответствовал используемому макросу. Например, вы можете по ошибке использовать макрос GetStockPen для получения хендла стандартного шрифта — так как макрос в итоге обратиться к универсальной функции GetStockObject, то фатальной ошибки не возникнет, просто возвращаемый результат будет приведен к некорректному типу (в примере: HPEN вместо HFONT).

8) Для создания собственных объектов применяются функции, начинающиеся со слова Create... Например, CreatePen или CreateSolidBrush.

9) Полученный объект (стандартный или созданный вами) выбирается в контекст устройства функцией:

HGDIOBJ SelectObject (hDC, hObject);

Эта функция возвращает хендл объекта того–же типа, выбранного ранее в этот контекст. В большинстве случаев может быть удобнее воспользоваться вместо функции SelectObject макросами из windowsx.h, предназначенными для работы с конкретными объектами:

HPEN SelectPen (hDC, hPen);

HBRUSH SelectBrush (hDC, hBrush);

HFONT SelectFont (hDC, hFont);

HBITMAP SelectBitmap (hDC, hBitmap);

10) Для получения информации об объекте применяется функция

int GetObject (hObject, nSize, lpvStruct);

где hObject — хендл объекта GDI, информацию о котором вы запрашиваете, lpvStruct — указатель на структуру данных, которая будет заполняться информацией об объекте; для объектов разных типов определены разные структуры (BITMAP, LOGPEN, LOGBRUSH, LOGFONT и т.д.), nSize — размер этой структуры.

11) Объект уничтожается функцией

BOOL DeleteObject (hObject);

Эта функция удаляет указанный объект, если только это не стандартный объект и если он не выбран в контекст устройства. Вместо одной универсальной функции в windowsx.h можно найти макросы, удаляющие объекты конкретных типов: DeletePen, DeleteBrush, DeleteFont и т.д.

Обычное использование

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

В качестве примера мы будем использовать только один объект GDI — перо, так как применение всех остальных типов объектов аналогично.

void Cls_OnPaint (HWND hwnd)

{PAINTSTRUCT ps;

HPEN hpenOld, hpenRed, hpenBlue;

BeginPaint (hwnd, &ps);

// создаем перья:

hpenRed = CreatePen (PS_SOLID, 0, RGB (255,0,0));

hpenBlue = CreatePen (PS_SOLID, 0, RGB (0,0,255));

// выбираем его в контекст и запоминаем прежнее:

hpenOld = (HPEN)SelectObject (ps.hdc, (HGDIOBJ)hpenRed);

... // осуществляем рисование красным пером

// выбираем другое перо, причем запоминать предыдущее не надо – оно

// и так известно - это hpenRed

SelectObject (ps.hdc, (HGDIOBJ)hpenBlue);

... // осуществляем рисование синим пером

// освобождаем созданное перо из контекста (то есть выбираем первоначальное)

SelectObject (ps.hdc, (HGDIOBJ)hpenOld);

// и удаляем созданные

DeleteObject ( (HGDIOBJ)hpenRed);

DeleteObject ( (HGDIOBJ)hpenBlue);

EndPaint (hwnd, &ps);}

Этот пример иллюстрирует все основные шаги по работе с создаваемыми объектами GDI. Однако в реальной жизни он используется не слишком часто — как правило при рисовании используется не один объект данного типа, а несколько. Это приводит к появлению большого количества переменных, как–то: hpen1, hpen2, ..., hpen100. Читаемость такого текста сравнительно невелика, да и вероятность запутаться остается высокой. Другое соображение — часто встречающееся приведение типов. В этом случае удобнее использовать макросы из windowsx.h. В третьих — сохранять исходный объект для восстановления его в контексте устройства не обязательно. Если существуют стандартные объекты данного типа, то вместо восстановления исходного можно перед удалением объектов выбрать в контекст любой стандартный того же типа (скажем, стандартных регионов или битмапов не определено — для них рекомендуется сохранять исходный).

В результате часто используются целые комбайны из функций GDI, как в приводимом ниже примере:

void Cls_OnPaint (HWND hwnd)

{PAINTSTRUCT ps;

BeginPaint (hwnd, &ps);

// создаем красное перо и выбираем его в контекст;

// прежнее НЕ запоминаем:

SelectPen (ps.hdc, CreatePen (PS_SOLID, 0, RGB (255,0,0)));

... // осуществляем рисование красным пером

// создаем и выбираем синее перо;

// предыдущее - созданное нами красное - сразу уничтожаем

DeletePen (SelectPen (ps.hdc, CreatePen (PS_SOLID, 0, RGB (0,0,255))));

... // осуществляем рисование синим пером

// освобождаем синее перо из контекста и уничтожаем его

DeletePen (SelectPen (ps.hdc, GetStockPen (BLACK_PEN)));

EndPaint (hwnd, &ps);}

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

Более редкий случай — когда объекты создаются при обработке WM_CREATE и уничтожаются при обработке WM_DESTROY (или при запуске и завершении приложения). Этот способ используется редко, так как требуется описание дополнительных статических переменных и, кроме того, интенсивнее расходуются ресурсы GDI.

LRESULT WINAPI _export WinProc (HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)

{PAINTSTRUCT ps;

static HPEN hpenRed; // хендл пера должен сохраняться в промежутке

// между обработкой сообщений

switch (uMsg) {case WM_CREATE:

...

hpenRed= CreatePen (PS_SOLID, 0, RGB (255,0,0));

break;

case WM_PAINT:

BeginPaint (hWnd, &ps);

SelectPen (ps.hdc, hpenRed);

... // здесь мы используем выбранный объект

// теоретически, объект сохраняется и после уничтожения контекста -

// так что мы можем не заменять его на стандартный; правда так делать

// не рекомендуется⁴

EndPaint (hWnd, &ps);

break;

case WM_DESTROY:

DeletePen (hpenRed);

...

break;

...

default:

return DefWindowProc (hwnd, uMsg, wParam, lParam);}

return 0L;}

Довольно часто, если объект создается на все время жизни окна, вместо статической переменной используются связанные с окном данные: либо размещенные в структуре окна (см. функции GetWindowLong, SetWindowLong), либо списки свойств окна (Property) (об этом см. методы связывания данных с окном).

Отображение основных графических объектов

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

При отображении отдельных пикселей атрибуты контекста устройства практически не используются — вы просто указываете цвет и положение пикселя, который хотите отобразить. На результат влияют только область отображения и характеристики устройства.

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

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

Задание цвета

При отображении любых графических объектов необходимо задавать их цвета. Сложности задания цвета начинаются из–за того, что различная аппаратура может воспроизводить только некоторое конечное число цветов. Одновременно вам может понадобиться осуществлять вывод сразу на несколько устройств, возможности которых по отображению цвета существенно различаются. Например — любой текстовой или графический редактор может взаимодействовать как с дисплеем, способным воспроизводить от нескольких цветов до миллионов цветов и принтером, который часто является монохромным.

Для обеспечения универсальности в GDI принято, что цвет обозначается с помощью 24^х битового параметра типа COLORREF. Этот параметр реально соответствует одному двойному слову, самый старший байт которого не используется. Младшие три байта задают интенсивности трех основных компонент цвета — красной, зеленой и синей. Каждая компонента задается своим байтом, так что предельный диапазон ее изменения лежит от 0 до 255. Это позволяет задавать до 16 777 216 различных цветов.

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

COLORREF RGB (byRed, byGreen, byBlue);

Конечно, Windows не всегда может использовать 24^х битовый цвет непосредственно, так как аппаратура может поддерживать от 2 цветов (монохроматические устройства) до более чем 16 млн. цветов (режимы TrueColor и HighColor для современных видеоадаптеров). Вместо отображения указанного вами цвета, GDI будет подбирать ближайший цвет, который в состоянии воспроизвести данная аппаратура в данном режиме; такой цвет называется чистый (pure color).

Внимание! на монохромных устройствах существует только два чистых цвета: черный и белый. Поэтому все цвета, имеющие сумму яркостей трех составляющих менее 381, представляются черными, а больше — белыми. Это может привести к неразличимости образа, если, например, вы по черному фону рисуете красную линию, или по белому — светло–циановую.

В некоторых случаях GDI может использовать вместо чистого цвета смесь точек разных цветов, наиболее точно передающих желаемый цвет. Такой цвет называется смешанным (dithered color). Однако такая операция выполняется далеко не всегда. Так при выводе текста цвет символов будет чистым цветом; аналогично линии (за небольшим исключением) рисуются тоже чистым цветом.

Работа с отдельными пикселями

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

Собственно, для рисования точек существуют всего две функции:

СOLORREF GetPixel (hDC, nX, nY);

COLORREF SetPixel (hDC, nX, nY, crColor);

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

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

Если используемый пиксель находится вне области рисования, то обе функции возвращают -1, а если пиксель находится внутри области рисования, то возвращаемое значение соответствует текущему цвету пикселя. Для функции SetPixel оно может отличаться от заданного crColor, указывая примененный чистый цвет (если ваша аппаратура не может отобразить требуемый цвет). Этот прием иногда используется для проверки возможностей устройства, хотя эффективнее анализировать возможности устройства с помощью функции GetDeviceCaps.

Рисование линий

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

Текущее перо (Pen).

Определяет вид проводимой линии — толщину, цвет, стиль (сплошная или прерывистая). Перо является объектом GDI, поэтому при его использовании необходимо соблюдать правила работы с объектами GDI.

Текущая позиция пера (Pen Position).

Определяет точку из которой начнется рисование следующего отрезка линии. После рисования этого отрезка текущая точка перемещается в конец отрезка.

Цвет фона (Background Color).

Заполняет промежутки между штрихами прерывистой линии (а также фон под символами выводимого текста или промежутки между линиями штрихованных кистей — об этом см. в обсуждении рисования заполненных фигур и обсуждении вывода текста).

Режим заполнения фона (Background Mode).

Определяет, надо–ли закрашивать промежутки между штрихами прерывистой линии цветом фона или оставить фон без изменений. Аналогично — при выводе текста.

Режим рисования (Drawing Mode).

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

Направление рисования дуг эллипсов (Arc Direction).

Влияет только на результат рисования дуги эллипса (функции Arc, Pie и Chord). По умолчанию дуги рисуются против хода часовой стрелки, но вы можете изменить это направление. Пользоваться этой возможностью, вообще говоря, не рекомендуется, так как применение этой функции ограничено — в Win32 API в расширенном режиме задания координат (см. SetGraphicsMode, GM_ADVANCED) дуги рисуются всегда против хода часовой стрелки и изменить это направление нельзя.

Собственно для рисования прямых линий необходимо всего две функции:

DWORD MoveTo (hDC, nX, nY); 0

BOOL MoveToEx (hDC, nX, nY, lpPoint);

BOOL LineTo (hDC, nX, nY);

Функция MoveToEx перемещает текущую точку пера в указанное место, не выполняя рисования. Последующий вызов функции LineTo осуществит рисование от текущей точки до указанной конечной отрезка. Нарисованный отрезок линии не включает в себя последнюю точку! Это сделано для удобства рисования ломанных линий из нескольких отрезков — в этом случае любая точка ломанной будет нарисована только один раз. Если вам необходимо нарисовать отрезок обязательно включая последнюю точку — продлите отрезок на один пиксель дальше (не забывайте, что вы задаете логические координаты, а удлинить отрезок надо на одну единицу устройства!). Если это сделать трудно (например отрезок наклонен под каким­–то углом) то можно дополнительно нарисовать крохотный отрезок длиной 1 пиксель в любую сторону.

В случае Windows API часто применялась функция MoveTo, а не MoveToEx; Функция MoveTo возвращала информацию о прежнем положении текущей точки, упакованную в двойное слово. В Win32 API такая упаковка невозможна — каждая координата уже представляет собой двойное слово — поэтому функция MoveTo больше не поддерживается.

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

BOOL Polyline (hDC, lpPoints, nCount);

Эта функция рисует ломаную линию, начальная, конечная и все точки перегиба которой заданы в массиве структур типа POINT (параметр lpPoints), содержащем nCount точек. Линия рисуется, начиная от первой точки и далее, соединяя последовательно отрезками все точки, вплоть до последней. Ломаная линия может быть незамкнутой, GDI не проводит замыкающего отрезка от последней точки к первой.

Еще одна функция GDI предназначена для рисования дуг:

BOOL Arc (hDC, xLeft, yTop, xRight, yBottom, xStart, yStart, xEnd, yEnd);

Для задания рисуемой дуги эллипса вы должны задать сначала сам эллипс, дуга которого будет изображаться, а затем задать начальную и конечную точки дуги. Эллипс задается описывающим его прямоугольником (причем нижняя и правая границы не включаются) — параметры xLeft, yTop, xRight и yBottom, а начальная и конечная точки задаются параметрами xStart, yStart и xEnd, yEnd.

Рисунок 18. Рисование дуг эллипсов

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

В случае применения Win32 API вы можете использовать еще несколько функций для рисования линий. Так две новых функции предназначены для рисования дуг:

BOOL ArcTo (hDC, xLeft, yTop, xRight, yBottom, xStart, yStart, xEnd, yEnd); 1

BOOL AngleArc (hDC, nX, nY, dwRadius, eStartAngle, eSweepAngle); 1

Функция ArcTo аналогична функции Arc, за исключением того, что она сначала рисует отрезок от текущей точки до начальной точки дуги, затем рисует саму дугу и перемещает текущую точку в конечную точку нарисованной дуги. Функция AngleArc рисует дугу окружности, не эллипса. Для нее надо задать центр окружности (параметры nX, nY), радиус (dwRadius), начальный угол (eStartAngle) и угловую величину рисуемой дуги (eSweepAngle), в градусах. GDI не проверяет угловую величину дуги, она может превышать 360⁰.

Еще пара новых функций предназначена для рисования ломаных линий:

BOOL PolylineTo (hDC, lpPoints, nCount); 1

BOOL PolyPolyline (hDC, lpPoints, lpuCounts, nPolyCount); 1

Функция PolylineTo отличается от Polyline тем, что начинает рисование с отрезка от текущей точки до первой точки, указанной в массиве, а после прорисовки всех отрезков перемещает текущую точку в последнюю точку массива. Функция PolyPolyline может за одну операцию отобразить несколько ломаных линий. Координаты всех точек всех линий задаются массивом структур POINT (параметр lpPoints), число точек в каждой ломаной линии задается массивом целых чисел lpuCounts, а число ломаных, рисуемых этой функцией — параметром nPolyCount.

Кроме того в Win32 API существуют функции для рисования кривых Безье:

BOOL PolyBezier (hDC, lpPoints, cPoints); 1

BOOL PolyBezierTo (hDC, lpPoints, cPoints); 1

Функция PolyBezier рисует линию состоящую из сегментов кривых Безье. Для задания каждого сегмента требуется указать четыре точки: начальную, две направляющие и конечная. Так как рисуется линия из нескольких сегментов, то конечная точка одного сегмента является в свою очередь начальной точкой другого сегмента. Таким образом кривая будет определяться набором из N_pt = 1 + N_segments*3; здесь N_pt — число точек для задания кривой, N_segments — число сегментов в кривой.

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

Функция PolyBezierTo отличается тем, что текущая точка используется в качестве начальной точки первого сегмента. В этом случае в массиве должно содержаться на одну точку меньше — только по две направляющих и одной конечной для каждого сегмента кривой. И, кроме того, после рисования кривой текущая точка будет перемещена в конечную точку последнего нарисованного сегмента.

Последняя рассматриваемая функция предназначена для рисования целого набора из прямых отрезков и кривых Безье за одну операцию:

BOOL PolyDraw (hDC, lpPoints, lpbyTypes, cCount); 1

Массивы структур POINT (lpPoints) и байтов (lpbyTypes) имеют одинаковое количество элементов; каждый элемент массива lpbyTypes определяет тип рисуемой линии из текущей точки до точки, задаваемой соответствующим элементом массива lpPoints. Допустимы следующие значения для типов линий:

Перо

Для проведения линий используется специальный объект GDI, который определяет вид проводимой линии, ее цвет и толщину. По аналогии с обычным рисованием на бумаге такой объект получил название перо (pen). Перо является объектом GDI, следовательно к нему применяются все правила работы с объектами GDI, рассмотренные ранее.

GDI предоставляет возможность использовать одно из трех стандартных перьев или создавать собственные перья, имеющие нужные свойства. Функция GetStockObject позволяет получить стандартное перо; они отличаются только цветом, проводимая ими линия всегда сплошная, шириной 1 единицу устройства (пиксель). Вместо функции GetStockObject можно использовать макрос GetStockPen из windowsx.h. Как и все стандартные объекты GDI эти перья нельзя уничтожать.

HANDLE GetStockObject (nIndex);

HPEN GetStockPen (nIndex); 2

BLACK_PEN	— черное перо
WHITE_PEN	— белое перо
NULL_PEN	— прозрачное перо

Куда больше возможностей предоставляют функции, создающие перья. Две из них — CreatePen и CreatePenIndirect отличаются только способом передачи параметров. Функция CreatePen получает все характеристики создаваемого пера в виде отдельных параметров, а функция CreatePenIndirect использует структуру LOGPEN, описывающую создаваемое перо. Функционально обе функции тождественны. Эта же структура используется функцией GetObject для получения информации о пере.

HPEN CreatePen (nPenStyle, nWidth, crColor);

HPEN CreatePenIndirect (lpLogPen);

typedef struct tagLOGPEN {

WORD lopnStyle; // стиль пера

POINT lopnWidth; // ширина линии

COLORREF lopnColor; // цвет пера

} LOGPEN;

Стиль пера может быть:

Ширина пера задается в логических единицах, причем в случае функции CreatePenIndirect для задания толщины используется структура типа POINT, в которой используется только поле x, а поле y — нет. Ширина пера задается в логических единицах. Так как логическая единица в общем случае может не совпадать с физической, то для создания тонких перьев (ширина которых равна 1 пикселю или одной строке растра) надо указать требуемую ширину равной 0 — тогда будет создано перо шириной 1 пиксель. Все прерывистые линии (PS_DOT, PS_DASH, PS_DASHDOT, PS_DASHDOTDOT), шириной больше физической 1 воспроизводятся как PS_SOLID.

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

Широкая линия проводится таким образом, что бы ее центр соединял указанные точки. Перо применяется не только для рисования линий, но и для рисования контура фигур. Если при этом используется широкая линия, то может быть удобно, что бы вся линия лежала внутри контура фигуры. Для таких целей предназначен стиль линии PS_INSIDEFRAME. Линии стиля PS_INSIDEFRAME отличаются еще одной особенностью: если ее ширина больше или равна 2 единицам устройства, то эта линия может рисоваться не чистым цветом, а смешанным.

При использовании Win32 API вы можете воспользоваться еще одной функцией для создания перьев:

HPEN ExtCreatePen (dwPenStyle, dwWidth, lpLogBrush, dwStyleCount, lpdwStyle); 1

typedef struct tagLOGBRUSH {

UINT lbStyle;

COLORREF lbColor;

LONG lbHatch;

} LOGBRUSH;

Перья, создаваемые этой функцией делятся на два типа: косметические (cosmetic) и геометрические (geometric). Для описания характеристик пера используется структура LOGBRUSH, обычно применяемая для описания кистей (см. раздел “Кисть”).

Косметические перья создаются, если в параметре dwPenStyle установлен стиль PS_COSMETIC. Они соответствуют тонким сплошным или прерывистым линиям (штриховым, штрих–пунктирным и пунктирным); всегда имеют ширину 1 пиксель (параметр dwWidth должен быть задан 1) и рисуются чистым цветом (цвет задается полем lbColor структуры LOGBRUSH; поле lbStyle обязательно должно быть BS_SOLID, а поле lbHatch не используется). Помимо стиля PS_COSMETIC надо задать один из дополнительных стилей:

Стили PS_SOLID, PS_DASH, PS_DOT, PS_DASHDOT, PS_DASHDOTDOT, PS_NULL, PS_INSIDEFARME в основном соответствуют уже рассмотренным стилям обычных перьев. (Для косметических ширина всегда равна 1 пикселю).

Стиль PS_ALTERNATE означает, что точки линии будут рисоваться через одну.

Если используется стиль PS_USERSTYLE, то два последних параметра функции ExtCreatePen задают стиль прерывистой линии: параметр lpdwStyle указывает на массив целых чисел, задающих длину штрихов и промежутков между ними; параметр dwStyleCount число записей в этом массиве. Внимание! длина штрихов и промежутков задается не в логических единицах, а в единицах устройства, непосредственно в процессе рисования линии.

Другой вид перьев — геометрические — создаются, если в параметре dwPenStyle указан стиль PS_GEOMETRIC. Такие перья могут быть произвольной толщины и цвета, включая узорчатые перья (рисунок на которых задается указанной кистью). Кроме того, при создании геометрических кистей есть возможность задать дополнительные стили. Так, в параметре dwPenStyle вы должны определить стиль PS_GEOMETRIC, стиль линии, стиль оформления окончаний и стиль сопряжения линий.

Стиль линии может быть PS_SOLID, PS_DASH, PS_DOT, PS_DASHDOT, PS_DASHDOTDOT, PS_NULL, PS_INSIDEFARME или PS_USERSTYLE. Стиль PS_ALTERNATE для геометрических перьев не поддерживается.

Стиль оформления окончаний играет роль для широких линий и может быть PS_ENDCAP_ROUND (конец линии полукруглый), PS_ENDCAP_SQUARE (в виде угла) и PS_ENDCAP_FLAT (прямой).

Стиль сопряжения линий влияет, если несколько последовательно проводимых отрезков сопрягаются под небольшим углом. Он может быть PS_JOIN_BEVEL (линии стыкуются под углом), PS_JOIN_ROUND (сопряжение скругляется) и PS_JOIN_MITER (сопряжение спрямляется). Если используется перо со стилем PS_JOIN_MITER, то дополнительно можно задать предельную величину спрямления сопрягаемых линий с помощью функции

BOOL SetMiterLimit (hDC, eNewLimit, lpeOldLimit); 1

BOOL GetMiterLimit (hDC, lpeOldLimit); 1

Величина спрямления задается относительно ширины линии.

Ширина геометрической линии может быть любой, она задается параметром dwWidth в логических единицах. Параметр lpLogBrush описывает кисть, которая задает цвет и узор линии; кисть может быть однотонной, смешанной, штрихованной или даже созданной по образцу — зависимому от устройства битмапу. Использование независимых от устройства битмапов в качестве образцов при описании пера недопустимо. О кистях и битмапах см. разделы “Кисть” и “”.

Как и в случае косметических перьев, параметры dwStyleCount и lpdwStyle определяют стиль штриховки, если задан стиль линии PS_USERSTYLE, иначе они не используются. Однако в отличие от косметического пера, ширина штрихов и промежутков задается в логических единицах.

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

BOOL DeleteObject (hGDIobj);

BOOL DeletePen (hPen);

Текущая позиция пера

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

С первыми тремя функциями мы уже познакомились — они–то и используются для рисования линий.

DWORD MoveTo (hDC, nX, nY); 0

BOOL MoveToEx (hDC, nX, nY, lpPoint);

BOOL LineTo (hDC, nX, nY);

Помимо них с текущей позицией пера имеют дело функции GetCurrentPosition и GetCurrentPositionEx а также, в некоторых случаях, функции TextOut и ExtTextOut.

DWORD GetCurrentPosition (hDC); 0

BOOL GetCurrentPositionEx (hDC, lpPoint);

Эти функции возвращают позицию пера. Как обычно — GetCurrentPosition возвращает ее в двойном слове и применятся только в 16^ти разрядном Windows API, тогда как функция GetCurrentPositionEx возвращает результат в структуре типа POINT и может применяться как в Windows API, так и в Win32 API.

Две другие функции — TextOut и ExtTextOut обычно не используют текущую позицию пера, вы должны им отдельно указывать позицию для вывода текста. Однако, иногда может быть удобно перейти в специальный режим привязки текста TA_UPDATECP (см. функцию SetTextAlign), при котором текст будет выводиться от текущей позиции, а после вывода текста текущая позиция переместится в конец выведенного фрагмента.

Цвет фона и режим заполнения фона

Еще один используемый атрибут контекста устройства — цвет фона. Это не тот цвет, которым закрашивается фон окна, хотя он может и совпадать с ним. Фон окна закрашивается не текущим цветом фона, а кистью, назначенной окну при регистрации класса. Цвет фона и режим заполнения фона используются:

функциями для рисования линий — для заполнения промежутков между штрихами прерывистой линии

функциями вывода текста — для заполнения пространства под символами текста.

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

Рисунок 18. Рисование прерывистых линий в разных режимах заполнения фона.

Для задания цвета фона и для выяснения текущего цвета вы можете воспользоваться функциями

COLORREF SetBkColor (hDC, crColor);

COLORREF GetBkColor (hDC);

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

В некоторых случаях бывает удобно проводить пунктирные и штрих–пунктирные линии так, что бы в промежутках был виден прежний фон (прежнее изображение), а не закрашивать их цветом фона. Для этого вы должны изменить режим заполнения фона. Для это предназначены функции:

int SetBkMode (hDC, nBkMode);

int GetBkMode (hDC);

GDI поддерживает два разных режима заполнения фона; один из них называется OPAQUE — это режим по умолчанию. В режиме OPAQUE промежутки заполняются текущим цветом фона, а в другом режиме, называемом TRANSPARENT, фон в промежутках не изменяется.

Режим рисования

Атрибут контекста устройства, называемый режим рисования, влияет на сам процесс рисования. Дело в том, что рисование на устройстве легко может быть представлено как операции над битовыми последовательностями, содержащими те или иные данные. Пока мы говорили о рисовании линии, подразумевая простейший перенос битового образа рисуемого объекта (линии) на другой битовый образ (уже имеющееся изображение).

Атрибут режим рисования задает правила, по которым GDI переносит информацию из одной битовой последовательности на другую. Так, помимо самого очевидного копирования возможны операции инверсии как уже имеющегося изображения, так и рисуемого, объединение с помощью различных битовых операций И (and), ИЛИ (or), ИСКЛЮЧАЮЩЕЕ ИЛИ (xor).

При рассмотрении процесса переноса изображения мы будем исходить из предположения монохромного устройства вывода, так как анализ процесса рисования на цветном устройстве выглядит громоздко. Говоря о монохромном устройстве мы будем обозначать светлую точку будем битом со значением 1, а для темную точку — 0.

При рисовании мы можем условно рассматривать три разные битовые последовательности:

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

контекст устройства, содержащий нарисованный ранее образ (хотя бы просто закрашенный фон), в документации называется destination;

результат — то изображение, которое будет находиться на контексте устройства после рисования;

Применительно к этим трем битовым последовательностям говорят о двоичной растровой операции (binary raster operation, ROP2), так как в формировании результата участвуют две исходных битовых последовательности.

Режим рисования задает операцию над битами обеих последовательностей, выполняемую в процессе переноса изображения. Всего возможно 16 различных режимов рисования:

Так, например, по умолчанию используется операция копирования исходного изображения на контекст устройства (называемая R2_COPYPEN), довольно часто применяется операция исключающее или (R2_XORPEN) между пером и существующим изображением на контексте.

Если монохроматические переносимое изображение и уже имеющееся рассматривать как битовые последовательности, то возможны 4 случая:

оба изображения, переносимое (pen) и имеющееся (destination), содержат светлые точки

переносимое изображение (pen) содержит светлую точку, а имеющееся (destination) — темную

переносимое изображение (pen) содержит темную точку, а имеющееся (destination) — светлую

оба изображения, переносимое (pen) и имеющееся (destination), содержат темные точки

Говоря в терминах битов может понадобиться комбинировать 1 с 1, 1 с 0, 0 с 1 и 0 с 0. Эти четыре варианта перечислены во втором столбце таблицы в заголовке. В строчках ниже дается ожидаемый результат во всех четырех случаях.

Например, если в результате комбинирования светлой со светлой должна получиться светлая точка (1 и 1 дает 1), а в остальных случаях — темная (1 и 0, 0 и 1, а также 0 и 0 дают 0), то в таблице эта операция будет обозначена как 1 0 0 0 — R2_MASKPEN.

Вы можете установить желаемый режим рисования, или узнать текущий с помощью функций

int SetROP2 (hDC, nIndex);

int GetROP2 (hDC);

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

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

Рисунок 18. Получение номера растровой операции.

Направление рисования дуг

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

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

int GetArcDirection (hDC);

int SetArcDirection (hDC, nIndex);

Допустимыми являются AD_COUNTERCLOCKWISE — рисование против хода часовой стрелки (принято по умолчанию) и AD_CLOCKWISE — по ходу часовой стрелки.

Внимание! Эти две функции не работают в случае расширенного режима задания координат (см. функцию SetGraphicsMode 1, GM_ADVANCED) — в этом случае дуги всегда рисуются против хода часовой стрелки.

Дополнительные средства для рисования линий

Windows содержит еще одну функцию, которая применяется для рисования линий. Она предназначена для последовательного вычисления координат точек, принадлежащих линии, и выполнения над этими точками какой-либо операции, определенной пользователем. Фактически эта функция для каждой точки рисуемой линии вызывает указанную пользователем процедуру. Любопытно, что сама эта функция никак не взаимодействует с контекстом устройства, она выполняет только математические операции, вычисляя все промежуточные точки линии.

void LineDDA (nXStart, nYStart, nXEnd, nYEnd, lpfnDdaPrc, lParam);

nXStart, nYStart — определяют первую точку линии

nXEnd, nYEnd — определяют последнюю точку линии

lpfnDdaPrc — указатель на процедуру типа LINEDDAPROC

lParam — данные, передаваемые пользователем процедуре LINEDDAPROC

Вызываемая процедура LINEDDAPROC имеет следующий вид:

void CALLBACK LineDDAproc (nX, nY, lParam) {

// ...}

Процедура LineDDAproc получает координаты точки, которую надо нарисовать и данные, переданные пользователем.

Координаты первой и последней точек задаются в произвольных единицах, так как их использование определяется не процедурой LineDDA, а процедурой LineDDAproc, разрабатываемой вами. Какие координаты вам удобнее — такие и используйте. Адрес процедуры lpfnDdaPrc в случае Windows API является адресом, возвращаемом функцией MakeProcInstance, но не адресом самой процедуры (об этом подробнее — в разделе «диспетчер памяти»). Данные, передаваемые пользователем, (lParam) являются двойным словом. В документации утверждается, что это дальний указатель на данные, хотя это некорректное утверждение. Часто параметр в виде двойного слова используется для задания адреса каких–либо данных (особенно, если данные занимают больше двух слов), однако реально там может удерживаться произвольное 32^х разрядное число. Более того, в прототипе функции он описан именно как long.

Рисование заполненных фигур

Следующая группа функций предназначена для отображения заполненных фигур. К таким фигурам относятся прямоугольники, прямоугольники со скругленными краями, эллипсы, сектора, дуги, стянутые хордой и многоугольники. Условно можно представить себе рисование заполненных фигур как процесс, состоящий из двух этапов — рисование контура текущим пером и заполнение фона. При рисовании контура справедливы все замечания, сделанные при обсуждении рисования линий. Если вам не надо рисовать контур, то выберите в контекст устройства прозрачный карандаш (функция GetStockObject или макрос GetStockPen, NULL_PEN). При заполнении фона рисуемой фигуры используются как уже рассмотренные атрибуты GDI, так и несколько новых. Естественно, что перед рисованием нужной вам фигуры вы должны установить требуемые значения атрибутов контекста устройства.

Кисть (Brush).

Кисть используется как для закраски внутренней области замкнутых фигур, так и для закраски внутренней области окна. Если фон фигуры заполнять не надо, то установите прозрачную кисть. Фактически кисть представляет собой маленький, 8x8 пиксель битмап, который многократно повторяется при заполнении указанной области. Кисть может быть как однотонной (все точки кисти имеют одинаковый цвет), так и штрихованной или узорчатой. Для штрихованных кистей определяется только цвет штрихов; цвет промежутков между штрихами определяется непосредственно при закраске области.

Цвет фона (Background Color).

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

Режим заполнения фона (Background Mode).

Определяет, надо–ли закрашивать промежутки между линиями штрихованных кистей цветом фона или оставить фон без изменений.

Режим рисования (Drawing Mode).

Определяет операцию, выполняемую в процессе переноса формируемого изображения на контекст устройства.

Направление рисования эллипсов (Arc Direction).

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

Режим заполнения многоугольников (Polygon Filling Mode).

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

Большинство перечисленных здесь атрибутов GDI уже рассмотрено в разделе «», так что повторно обсуждаться они не будут. Ниже отдельно вынесено обсуждение двух новых атрибутов: кисть и режим заполнения многоугольников.

Функции для рисования заполненных фигур

Среди всех функций, рисующих заполненные объекты, можно условно выделить группу функций, для выполнения которых вы должны задать описывающий рисуемый объект прямоугольник. К таким функциям относятся функции по рисованию прямоугольника (Rectangle), прямоугольника со скругленными краями (RoundRect), эллипса (Ellipse), а также функции для рисования сектора (Pie) и дуги, стянутой хордой (Chord). Все эти функции требуют задания либо непосредственно рисуемого прямоугольника, либо прямоугольника, в который будет вписан рисуемый объект (прямоугольник со скругленными углами, весь рисуемый эллипс или эллипс, дуга которого используется для рисования сектора или стягивается хордой).

При задании описывающего прямоугольника необходимо учитывать несколько нюансов:

Во–первых, по умолчанию нижняя и правая границы описывающего прямоугольника не включаются в рисуемый объект, однако в случае Win32 API и установленного расширенного режима границы описывающего прямоугольника полностью включаются в рисуемый объект (функция SetGraphicsMode, GM_ADVANCED, дополнительно см. раздел «»).

Во–вторых, рисуемый объект может выходить за рамки описывающего прямоугольника, если для обведения контура используется перо, ширина которого превышает одну единицу устройства и это перо не стиля PS_INSIDEFRAME. Линия стиля PS_INSIDEFRAME всегда будет находиться внутри описывающего прямоугольника.

В–третьих, ориентация сторон описывающего прямоугольника всегда параллельна осям координат и, соответственно, предусмотренные функции не могут рисовать наклонных прямоугольников и эллипсов, что является существенным неудобством. Единственное возможность — при использовании Win32 API перейти в расширенный режим и наклонить сами оси координат (см. раздел «»).

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

BOOL Rectangle (hDC, xLeft, yTop, xRight, yBottom);

BOOL Ellipse (hDC, xLeft, yTop, xRight, yBottom);

BOOL RoundRect (hDC, xLeft, yTop, xRight, yBottom, xRound, yRound);

Функция Rectangle рисует прямоугольник с прямыми углами, а функция RoundRect скругляет эти углы, проводя небольшие дуги. Эти функции используют описывающий прямоугольник, координаты которого задаются в качестве параметров, причем для функций Rectangle и RoundRect этот прямоугольник задает непосредственно рисуемый объект, а для функции Ellipse он задает описывающий прямоугольник. Функция RoundRect дополнительно требует задания величины эллипсов, которыми она будет скруглять углы. При этом надо учитывать, что задаются размеры описывающего скругляющий эллипс прямоугольника, а не его радиусы. То есть в каждом углу скругляющая дуга будет занимать только половину от указанных вами значений.

Рисунок 18. Задание величины скругляющих эллипсов для функции RoundRect.

Теперь осталось рассмотреть пару функция для рисования сектора (Pie), то есть дуги и области, ограниченной двумя радиусами и для рисования дуги, стянутой хордой (Chord).

Рисунок 18. Результат выполнения функций Pie (слева) и Chord (справа).

BOOL Pie (hDC, xLeft, yTop, xRight, yBottom, xStart, yStart, xEnd, yEnd);

BOOL Chord (hDC, xLeft, yTop, xRight, yBottom, xStart, yStart, xEnd, yEnd);

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