Это вторая из двух глав в книге, описывающая элементы взаимодействия непосредственно с пользователем, т.е. вывод информации на экран и прием пользовательского ввода с помощью мыши или клавиатуры. В главе 9 мы рассматривали формы Windows и узнали, как выводить диалоговое окно или окна SDI и MDI и как разместить в них различные элементы управления, такие как кнопки, текстовые поля и поля списков. Основное внимание было уделено использованию элементов управления на основе их способности взять на себя полную ответственность за собственное изображение на устройстве вывода. Необходимо только задать свойства элемента управления и добавить методы обработки событий. Стандартные элементы управления — очень мощные, можно получить сложный интерфейс пользователя, используя только их. На самом деле они сами по себе вполне достаточны для полного интерфейса при работе со многими приложениями, в частности диалогового типа или с интерфейсом пользователя типа проводника.

Однако существуют ситуации, в которых простые элементы управления не дают гибкости, требуемой в интерфейсе пользователя. Иногда необходимо ввести текст заданным шрифтом в точной позиции окна или нарисовать изображения, не используя элемент управления "графическая кнопка", простые контуры или другую графику. Хорошим примером является программа Word for Windows. В верхней части экрана находятся различные кнопки и панели инструментов, которые используются для доступа к различным свойствам Word. Некоторые из меню и кнопок вызывают диалоговые окна или даже списки свойств. Эта часть интерфейса пользователя была рассмотрена в главе 9. Но основная часть экрана в Word for Windows будет совершенно другой. Окно SDI выводит представление документа. Оно имеет текст, аккуратно расположенный в нужных местах и выведенный с использованием множества размеров и шрифтов. В документе может быть выведена любая диаграмма и, если посмотреть на документ компоновки для печати, поля реальных страниц также должны быть выведены. Ничего из этого нельзя сделать с помощью элементов управление, описанных в главе 9. Чтобы изобразить такой вывод, программа Word for Windows должна взять на себя прямую ответственность за сообщение операционной системе, что необходимо вывести и где в его окне SDI. Как это делается, объясняется в данной главе. Здесь будет показано, как рисовать различные элементы, включая:

□ Линии, простые контуры

□ Изображения из растровых и других файлов изображении

□ Текст 

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

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

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

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

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

CapsEditor

CapsEditor

Библиотека базовых классов GDI+ очень велика, и мы едва сможем прикоснуться к их свойствам в данной главе. Это обдуманное решение, так как попытка охватить хотя бы минимальную часть доступных классов, методов и свойств превратит эту главу в справочное руководство, которое просто перечисляет классы и т. д. Более важно понять фундаментальные принципы, вовлеченные в рисование, а затем можно будет исследовать доступные классы самостоятельно. (Полные списки всех доступных в GDI+ классов и методов имеются в документации MSDN). Разработчики, имеющие дело с VB, найдут, скорее всего, концепции, вовлеченные в рисование, совершенно незнакомыми, так как фокус VB заключается в элементах управления, обрабатывающих свое собственное рисование. Разработчики с подготовкой C++/MFC окажутся в более выгодном положении, так как MFC требует в большей степени внешнего управления процессом рисования, используя предпроцессор GDI+, GDI. Однако даже при хорошем знакомстве с GDI подавляющая часть материала окажется новой. GDI+ в действительности является оболочкой GDI, но тем не менее GDI+ имеет объектную модель, которая скрывает большую часть работы GDI. В частности GDI+ заменяет почти полностью модель с состоянием GDI, в которой элементы выбирались в контексте устройства, на модель, менее учитывающую состояние, в которой каждая операция рисования происходит независимо. Объект Graphics (представляющий контекст устройства) является единственным объектом, существующим между операциями рисования.

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

Прежде коротко перечислим основные пространства имен, которые встречаются в базовых классах GDI+.

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

System.Drawing

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

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

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

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

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

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

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

При использовании GDI+ контекст устройства по-прежнему существует, хотя ему теперь дано другое имя. Он завернут в базовый класс .NET с именем

Graphics

Graphics

System.Drawing.Graphics

Graphics

Мы собираемся начать с короткого примера для рисования в основном окне приложения. Все примеры в этой главе созданы с помощью Visual Studio.NET как приложения Windows на C#. Вспомните, что для проекта такого типа мастер кода определяет класс с именем

Form1

System.Windows.Form

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

В первом примере создается просто форма и на ней рисуется в методе

InitializeComponent()

В данном случае мы запускаем Visual Studio.NET, создаем приложение Windows и изменяем код в методе

InitializeComponent()

private void InitializeComponent() {

 this.components = new System.ComponentModel.Container();

 this.Size = new System.Drawing.Size(300, 300);

 this.Text = "Display At Startup";

 this.BackColor = Color.White;

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

Form1

public Form1() {

 InitializeComponent();

 Graphics dc = this.CreateGraphics();

 this.Show();

 Pen BluePen = new Pen(Color.Blue, 3);

 dc.DrawRectangle(BluePen, 0, 0, 50, 50);

 Pen RedPen = new Pen(Color.Red, 2);

 dc.DrawEllipse(RedPen, 0, 50, 80, 60);

}

Это единственные изменения, которые необходимо сделать. Наш пример является примером

DisplayAtStartup

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

InitializeComponent()

InitializeComponent()

Затем мы создаем объект

Graphics

CreateGraphics()

Graphics

Graphics

Далее для выведения окна вызывается метод

Show()

Наконец, мы выводим прямоугольник в точке с координатами (0, 0) с шириной и высотой равной 50 и эллипс в точке с координатами (0, 50) с шириной 80 и высотой 50. Отметим, что координаты (х, у) означают х пикселей вправо и у пикселей вниз от верхнего левого угла клиентской области окна и являются координатами верхнего левого угла изображаемой фигуры:

Запись (х, у) является стандартной математической записью, очень удобной для описания координат. Используемые методы

DrawRectanglе()

DrawEllipse()

System.Drawing.Pen

Более подробно эти новые структуры и методы объекта Graphics будут рассмотрены позже.

Выполнение данного кода приведет к следующему результату:

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

BackColor

Pen.Alignment

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

Что же делать? Проблема возникает, если окно или его часть становятся скрытыми по какой-либо причине (например, оно минимизируется или закрывается другим окном), Windows обычно немедленно отбрасывает всю информацию, относящуюся к тому, что там было изображено. Система должна это делать, иначе используемая память для хранения данных экрана будет слишком большой. Типичный компьютер может работать с видеоплатой, настроенной для вывода 1024×768 пикселей, возможно, в режиме с 24-битовым цветом. Мы покажем, что означает 24-битовый цвет позже, но в данный момент можно сказать, что каждый пиксель на экране занимает 3 байта, т. е. 2.25 Мбайт для изображения экрана. Однако нет ничего необычного, если пользователь имеет во время работы более 10 минимизированных окон в своей панели задач, в худшем сценарии 20, каждое из которых занимает весь экран, если оно не минимизировано. Если бы Windows действительно хранил визуальную информацию, которую содержат эти окна, готовую на случай, если пользователь захочет их восстановить, то речь шла бы о 45 Мбайт. Сегодня хорошая графическая карта может иметь 64 Мбайта памяти, но еще пару лет назад 4 Мбайта считалось большим объемом для графической платы, а избыточные данные необходимо было хранить в основной памяти компьютера. Множество людей все еще используют старые машины. Очевидно, что для Windows было бы непрактично управлять интерфейсом своих пользователей подобным образом.

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

Это проблема для нашего примера приложения. Мы поместили код рисования в конструктор

Form1

В главе 9 при рассмотрении элементов управления нам ничего этого не нужно было знать, так как стандартные элементы управления достаточно развиты и могут правильно перерисовать себя, когда Windows об этом попросит. Это одна из причин, почему при программировании элементов управления вообще не нужно беспокоиться о реальном процессе рисования. Если мы берем на себя ответственность в приложении за рисование на экране, то нам нужно также гарантировать, что приложение будет отвечать правильно, когда Windows попросит перерисовать все или часть окна. В следующем разделе мы изменим пример так, чтобы это было возможно.

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

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

Paint

Form

Form1

Paint

OnPaint()

PaintEventArgs

OnPaint()

DrawShapes

DrawShapes

Form1

protected override void OnPaint(PaintEventArgs e) {

 Graphics dc = e.Graphics;

 Pen BluePen = new Pen(Color.Blue, 3);

 dc.DrawRectangle(BluePen, 0, 0, 50, 50);

 Pen RedPen = new Pen(Color.Red, 2);

 dc.DrawEllipse(RedPen, 0, 50, 80, 60);

 base.OnPaint(e);

}

Отметим, что метод

OnPaint()

protected

OnPaint()

PaintEventArgs

EventArgs

PaintEventArgs

Graphics

CreateGraphics()

OnPaint()

В данной реализации метода

OnPaint()

Graphics

PaintEventArgs

OnPaint()

OnPaint()

OnPaint()

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

base.OnPaint()

OnPaint()

private void InitializeComponent() {

 this.components = new System.ComponentModel.Container();

 this.Size = new System.Drawing.Size(300, 300);

 this.Text = "Draw Shapes";

 this.BackColor = Color.White;

}

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

Пример приложения

DrawShapes

DrawShapes

DrawShapes

До сих пор все хорошо. А что произойдет, когда перекрывающее окно (в данном случае Task Manager) будет удалено, так что окно

DrawShapes

Paint

OnPaint()

OnPaint()

В таком случае фигуры не нужно перерисовывать. Причина этого связана с контекстом устройства. Ранее говорилось, что контекст устройства внутри объекта

Graphics

OnPaint()

Вследствие этого запрос экземпляра

Graphics

Graphics

DrawShapesWithClipping

DisplayShapes

OnPaint()

Сначала необходимо получить данные области вырезания. Для этого используется дополнительное свойство

PaintEventArgs

ClipRectangle

System.Drawing.Rectangle

Rectangle

Top

Bottom

Left

Right

Затем надо решить, какой тест будет использоваться для рисования. Здесь будет использован простой тест. Отметим, что прямоугольник и эллипс полностью содержатся внутри прямоугольника, который простирается в клиентской области от точки (0, 0) до точки (80, 130), в действительности до точки (82, 132), так как мы знаем, что линии могут отклоняться примерно на пиксель вне этой области. Поэтому будем проверять, что верхний левый угол области вырезания находится внутри этого прямоугольника. Если это так, то выполняется рисование. Если нет, то ничего не делается. Код выглядит следующим образом:

protected override void OnPaint(PaintEventArgs e) {

 Graphics dc = e.Graphics;

 if (e.ClipRectangle.Tор < 132 && e.ClipRectangle.Left < 82) {

  Pen BluePen = new Pen(Color. Blue, 3);

  dc.DrawRectangle(BluePen, 0, 0, 50, 50);

  Pen RedPen = new Pen(Color.Red, 2);

  dc.DrawEllipse(RedPen, 0, 50, 80, 60);

 }

 base.OnPaint(e);

}

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

OnPaint()

OnPaint()

Graphics

Graphics

В последнем примере мы встретили базовую структуру

Rectangle

System.Drawing

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

Рассмотрим сначала

Point

Чтобы перейти из точки А в точку В, необходимо сместиться на 20 единиц вправо и на 10 единиц вниз, помеченных как X и Y на рисунке, так как это обычное обозначение. Можно было бы создать структуру

Point

Point АВ = new Point(20, 10);

Console.WriteLine("Moved {0} across, {1} down", AB.X, AB.Y);

X и Y являются свойствами чтения-записи, а значит, можно также задать значения в

Point

Point АВ = new Point();

AB.X = 20;

АВ.Y = 10;

Console.WriteLine("Moved (0) across, (1) down", AB.X, AB.Y);

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

Point

X

Y

PointF

Point

X

Y

float

int

PointF

Point

PointF

PointF

Point

PointF ABFloat = new PointF(20.5F, 10.9F);

Point AB = (Point)ABFloat;

PointF ABFloat2 = AB;

Одно последнее замечание о координатах. В нашем обсуждении

Point

PointF

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

Graphics

Point(20, 10)

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

Подобно

Point

PointF

Size

SizeF

Size

SizeF

Size

Во многом

Size

Point

X

Y

Width

Height

Size АВ = new Size(20, 10);

Console.WriteLine("Moved {0} across, {1} down", AB.Width, AB.Height);

Строго говоря структура

Size

Point

Point

Size

В качестве примера рассмотрим нарисованный ранее прямоугольник с координатой вверху слева (0, 0) и размером (50, 50):

Graphics dc. = е.Graphics;

Pen BluePen = new Pen(Color.Blue, 3);

dc.Rectangle(BluePen, 0, 0, 50, 50);

Размер этого прямоугольника равен (50, 50) и может быть представлен экземпляром

Size

Point

dc.DrawRectangle(BluePen, 10, 10, 50, 50);

Теперь нижний правый угол имеет координаты (60, 60), но размер не изменился — по-прежнему (50, 50).

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

static void Main(string [] args) {

 Point TopLeft = new Point (10, 10);

 Size RectangleSize = new Size(50, 50);

 Point BottomRight = TopLeft + RectangleSize;

 Console.WriteLine("TopLeft = " + TopLeft);

 Console.WriteLine("BottomRight = " + BottomRight);

 Console.WriteLine("Size = " + RectangleSize);

}

Этот код, выполняемый как простое консольное приложение, создает следующий вывод:

Отметим, что этот вывод показывает также, как метод

ToString()

Point

Size

Аналогично можно вычесть

Size

Point

Point

Size

Size

Point

Point

Можно также явно преобразовать

Point

Size

Point TopLeft = new Point(10, 10);

Size S1 = (Size)TopLeft;

Point P1 = (Point)S1;

При этом преобразовании значению

S1.Width

TopLeft.X

S1.Height

TopLeft.Y

S1

P1

TopLeft

Эти структуры предcтавляют прямоугольную область (обычно на экране). Так же, как и в случае с

Point

Size

Rectangle

RectangleF

float

Rectangle

int

Rectangle

Size

Point

Size

Graphics dc = е Graphics;

Pen BluePen = new Pen(Color Blue, 3);

Point TopLeft = new Point(0, 0);

Size HowBig = new Size(50, 50);

Rectangle RectangleArea = new Rectangle(TopLeft, HowBig);

dc.DrawRectangle(BluePen, RectangleArea);

Этот код также использует альтернативное переопределение

Graphics.DrawRectangle()

Pen

Rectangle

Можно также создать

Rectangle

Rectangle RectangleArea = new Rectangle(0, 0, 50, 50)

Rectangle

Отметим, что эти свойства не все независимы,— например задание

Width

Right

Мы упомянем здесь о существовании класса

System.Drawing.Region

Region

Region

Процесс инициализации экземпляра

Region

Region

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

Paint

OnPaint

Типичный сценарий будет таков: необходимо определить, почему приложение что-то выводит неправильно, поэтому в

OnPaint

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

Paint

OnPaint

Однако существуют способы обхода этой проблемы.

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

TopMost

Form

InitializeComponent

private void InitializeComponent() {

 this.TopMost = true;

Это означает, что приложение никогда не будет закрыто другими окнами (только другими самыми верхними окнами). Оно всегда остается поверх других окон, даже когда другое приложение получает фокус. Так ведет себя менеджер задач.

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

Paint

OnPaint

OnPaint

if

protected override void OnPaint(PaintEventArgs e) {

 // Condition() оценивается как true, когда требуется прерывание

 if (Condition() == true) {

  int ii = 0; // <-- ЗАДАТЬ ЗДЕСЬ ТОЧКУ ПРЕРЫВАНИЯ

 }

Это быстрый и простой способ создания условной точки прерывания.

Наш ранний пример

DrawShapes

Расширим пример

DrawShapes

BigShapes

Point

Size

Rectangle

Form1

// поля-члены

private Point reсtangleTopLeft = new Point(0, 0);

private Size rectangleSize = new Size(200, 210);

private Point ellipseTopLeft = new Point(50, 200);

private Size ellipseSize = new Size(200, 150);

private Pen bluePen = new Pen(Color.Blue, 3);

private Pen redPen = new Pen(Color.Red, 2);

private void InitializeComponent() {

 this.components = new System.ComponentModel.Container();

 this.Size = new System.Drawing.Size(300, 300);

 this.Text = "Scroll Shapes";

 this.BackColor = Color.White;

}

#endregion

protected override void OnPaint(PaintEventArgs e) (

 Graphics dc = e.Graphics;

 if (e.ClipRectaringle.Top < 350 || e.ClipRectangle.Left < 250) {

  Rectangle RectangleArea =

   new Rectangle(RectangleTopLeft, RectangleSize);

  Rectangle EllipseArea =

   new Rectangle(EllipseTopLeft, EllipseSize);

  dc.DrawRectangle(BluePen, RectangleArea);

  dc.DrawEllipse(RedPen, EllipseArea);

 }

 base.OnPaint(e);

}

Отметим, что мы превратили объекты

Pen

Pen

Результат выполнения этого примера выглядит следующим образом:

Сразу можно увидеть проблему. Фигуры не вписываются в область рисования 300×300 пикселей.

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

Если форма имеет различные элементы управления, присоединенные к ней, то экземпляр класса

Form

Form

Form

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

Добавление панелей прокрутки делается очень просто. Объект

Form

Сообщить форме размер документа достаточно просто. Мы используем соответствующее свойство

Form.AutoScrollMinSize

private void InitializeComponent() {

 this.components = new System.ComponentModel.Container();

 this.Size = new System.Drawing.Size(300, 300);

 this.Text = "Scroll Shapes";

 this.BackColor = Color.White;

 this.AutoScrollMinSize = new Size(250, 350);

}

Отметим, что здесь мы имеем

MinScrollSize

InitializeComponent

Задания

MinScrollSize

ScrollShapes

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

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

Очевидно, что-то происходит неправильно.

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

OnPaint()

Фигуры нарисованы, как и раньше, с верхним левым углом прямоугольника, помещенным в верхний левый угол клиентской области, как если бы панель прокрутки вообще не перемещалась.

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

Посмотрим сначала на последний снимок экрана, с которым проще иметь дело. Пример

ScrollShapes

Graphics

Graphics

Теперь посмотрим на более ранний снимок экрана — сразу после прокрутки изображения вниз. Мы замечаем, что здесь верхние две трети окна выглядят нормально. Это связано с тем, что они были нарисованы, когда приложение запускалось в первый раз. При прокрутке окна Windows не просит приложение перерисовать то, что уже было на экране. Система Windows достаточно разумна, чтобы самостоятельно определить, какие биты из изображаемых в данный момент на экране могут плавно переместиться, чтобы соответствовать текущему положению панели прокрутки. Это значительно более эффективный процесс, так как он может использовать некоторые аппаратные средства ускорения. Часть этого изображения экрана, которая выглядит неправильно, составляет нижнюю треть окна. Эта часть окна не была нарисована, когда приложение появилось на экране впервые, так как до начала прокрутки она находилась вне клиентской области. Значит, система Windows просит приложение

ScrollShapes

Paint

OnPaint()

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

Graphics

Point

Проблема в том, что неизвестно, каким будет вектор из А в Р. Мы знаем, какой будет вектор из В в Р, это просто координаты Р относительно верхнего левого угла документа, позиция, где мы хотим нарисовать в документе точку Р. Мы знаем также, какой будет вектор из В в А — это величина, на которую была выполнена прокрутка; она хранится в свойстве класса

Form

AutoScrollPosition

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

Graphics

TranslateTransform

Graphics

После всех этих объяснений осталось только добавить следующую строку кода в код рисования

dc.TranslateTransform(this.AutoScrollPosition.X, this.AutoScrollPosition.Y);

Фактически в нашем примере это происходит немного сложнее, так как мы по отдельности контролируем область вырезания, проверяя, нужно ли делать какое-либо рисование. Мы должны настроить эту проверку с учетом положения прокрутки, после чего весь код рисования для этого примера (загружаемый с web-сайта Wrox Press как

ScrollShapes

protected override void OnPaint(PaintEventArgs e) {

 Graphics dc = e.Graphics;

 Size ScrollOffset = new Size(this.AutoScrollPosition);

 if (e.ClipRectangle.Top + ScrollOffset.Width < 350 || e.ClipRectangle.Left + ScrollOffset.Height < 250) {

  Rectangle RectangleArea =

   new Rectangle(RectangleTopLeft + ScrollOffset, RectangleSize);

  Rectangle EllipseArea =

   new Rectangle(EllipseTopLeft + ScrollOffset, EllipseSize);

  dc.DrawRectangle(BluePen, RectangleArea);

  dc.DrawEllipse(RedPen, EllipseArea);

 }

 base.OnPaint();

}

Теперь код прокрутки работает прекрасно, мы можем, наконец, получить правильно прокрученный снимок экрана.

Различие в измерениях позиции относительно верхнего левого угла документа и относительно верхнего левого угла экрана является настолько значительным, что GDI+ имеет для них специальные названия.

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

□ Координаты страницы являются позицией точки, измеренной в пикселях от верхнего левого угла клиентской области. Название идет от представления выводимой области как "страницы" выводимых данных.

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

LPtoDP()

и

DPtoLP()

. В GDI+ информацию, необходимую для выполнения преобразования, поддерживает объект

Form

.

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

Graphics.PageUnit

PageUnit

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

Цвета в GDI+ представлены экземплярами структуры

System.Drawing.Color

Color

Form.BackColor

Color

Общее число цветов, которое можно изобразить на мониторе, огромно — более 16 млн. Точнее, оно равно 2 в 24-й степени, что составляет 16777216. Требуется некоторый способ индексирования этих цветов, чтобы можно было указать, какой цвет мы хотим использовать для данного пикселя.

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

Теперь можно понять, откуда появляется число 16777216, оно равно 256 в кубе.

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

Color.FromArgb()

Color RedColor = Color.FromArgb(255, 0, 0);

Color FunnyOrangyBrownColor = Color.FromArgb(255, 155, 100);

 Color BlackColor = Color.FromArgb(0, 0, 0);

Color WhiteColor = Color.FromArgb(255, 255, 255);

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

FromArgb()

Создание структуры

Color

FromArgb()

Color

this.BackColor = Color.White;

// имеет такой же эффект, как и

// this.BackColor = Color.FromArgb(255, 255, 255);

Существует несколько сотен таких цветов. Полный список дан в документации MSDN. Он включает все простые цвета:

Red

White

Blue

Green

Black

MediumAquamarine

LightCoral

DarkOrchid

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

При том что в принципе мониторы могут вывести любой из 16 млн цветов RGB, на практике это зависит от того, как заданы свойства вывода изображения на компьютере. Делая щелчок правой кнопкой мыши на рабочем столе Windows и выбирая Settings в появляющейся таблице свойств, можно получить цветовое разрешение изображения. Здесь традиционно существует три основных варианта (хотя некоторые машины могут предоставлять другие возможности в зависимости от оборудования): true color (24-битовые), high color (16-битовые) и 256 цветов. (На некоторых графических платах сегодня true color в действительности помечены как 32-битовые с целью оптимизации аппаратного обеспечения, хотя в этом случае для самого цвета используются только 24 бита из 32).

Только режим true color позволяет выводить одновременно все цвета RGB. Это лучший вариант, но требует дополнительных расходов: для хранения полного значения RGB требуется 3 байта, т. е. для хранения каждого выводимого пикселя требуется 3 байта памяти графической платы. Если памяти графической платы достаточно (ограничение, которое встречается сегодня реже), то можно выбрать такой режим. Режим high color использует два байта на пиксель. Этого достаточно, чтобы задать 5 битов для каждой компоненты RGB. Поэтому вместо 256 градаций интенсивности красного, получается только 32 градации; то же самое для синего и зеленого, что дает всего 65536 цветов. Этого вполне достаточно, чтобы получить почти фотографическое качество при поверхностном рассмотрении, хотя области с легким затенением покажутся слегка неровными.

256-цветовой режим дает еще меньше цветов. Однако в этом режиме можно выбрать используемые цвета. В системе задается так называемая палитра. Это список 256 цветов, выбранных из 16 миллионов цветов RGB. После задания цветов в палитре графическое устройство может выводить только эти цвета. Палитра изменяется в любое время, но графическое устройство по-прежнему выведет только 256 различных цветов в данный момент времени. 256-цветный режим используется в действительности только, когда необходимо получить высокую производительность и при небольшом объеме видеопамяти. Большинство игр будут использовать этот режим, но за счет тщательного выбора палитры они по-прежнему смогут предоставить хорошее графическое оформление.

Вообще, если устройство вывода находится в режиме high color или 256 цветов и запрашивается для вывода определенного цвета RGB, то оно будет выбирать ближайшее математическое соответствие из пула доступных цветов. По этой причине важно знать о режимах цветов. При рисовании объекта, который содержит слабые затенения или имеет фотографическое качество, и если не выбран режим 24-битовых цветов, пользователь может не увидеть изображения в том виде, как это должно быть. Если работа такого рода делается с помощью GDI+, необходимо проверить приложение в различных режимах цветов. (Приложение может также программным путем задать цветовой режим, хотя этот вопрос здесь рассматриваться не будет).

Для справки мы кратко упомянем здесь палитру безопасности. Это обычно палитра, используемая по умолчанию. Она работает так, что для каждого цветового компонента задается шесть расположенных на одинаковом расстоянии друг от друга возможных значений. А именно, значения 0, 51, 102, 153, 204, 255. Другими словами, красный компонент может иметь любое из этих значений. То же самое можно сказать о зеленом и синем компонентах. Поэтому возможные цвета из палитры безопасности включают (0, 0, 0) (черный), (153, 0, 0) (достаточно темный оттенок красного), (0, 255, 102) (зеленый с небольшой голубизной) и т. д. Это дает всего 6 в кубе = 216 цветов. Идея состоит в том, что это дает нам простой способ иметь палитру, которая содержит цвета из всего спектра и всех степеней яркости, хотя на практике это работает не так хорошо, так как равное математическое разделение цветовых компонентов не значит равного восприятия различия цветов человеческим глазом. Но поскольку палитра безопасности широко используется, можно найти большое число приложений и изображений, которые используют цвета исключительно из палитры безопасности.

При использовании 256-цветного режима Windows палитрой по умолчанию является палитра безопасности с добавленными 20 стандартными цветами Windows и 20 свободными цветами.

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

Graphics

System.Drawing.Brush

Pen

Brush

Рассмотрим сначала кисти, а затем — перья.

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

SelectObject()

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

SelectObject()

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

GDI+ имеет несколько различных видов кистей, мы объясним простейшие из них, чтобы знать о принципах. Каждый тип кисти представлен экземпляром класса, производным из

System.Drawing.Brush

Brush

System.Drawing.SolidBrush

Brush solidBeigeBrush = new SolidBrush(Color.Beige);

Brush solidFunnyOrangyBrownBrush = new SolidBrush(Color.FromArgb(255, 155, 100)

Альтернативно, если кисть является одним из именованных цветов Интернета, то можно создать кисть более просто с помощью другого класса

System.Drawing.Brushes

Brushes

Brushes

Brush solidAzureBrush = Brushes.Azure;

Brush solidChocolateBrush = Brushes.Chocolate;

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

Drawing2D

System.Drawing.Drawing2D.HatchBrush

Brushes

System.Drawing.Drawing2D.HatchStyle

HatchStyle

ForwardDiagonal

Cross

DiagonalCross

SmallConfetti

ZigZag

Brush crossBrush = new HatchBrush(HatchStyle.Cross, Color.Azure);

// фоновый цвет для CrosstBrush будет черный

Brush brickBrush = new HatchBrush(HatchStyle.DiagonalBrick, Color.DarkGoldenrod.Color.Cyan);

Сплошные и штриховые кисти — единственные кисти, доступные в GDI. GDI+ добавляет пару новых стилей кисти:

□ Кисть

System.Drawing.Drawing2D.LinearGradientBrush

□ Кисть

System.Drawing.Drawmg2D.PathGradientBrush

Bezier

В отличие от кистей перья представлены только одним классов —

System.Drawing.Pen

Alignment

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

Brush

Pen

float

Graphics

Brush brickBrush = new HatchBrush(HatchStyle.DiagonalBrick, Color.DarkGoldenrod, Color.Cyan);

Pen solidBluePen = new Pen(Color.FromArgb(0, 0, 255));

Pen solidWideBluePen = new Pen(Color.Blue, 4);

Pen brickPen = new Pen(BrickBrush);

Pen brickWidePen = new Pen(BrickBrush, 10);

Кроме того, для быстрого создания перьев можно использовать класс

System.Drawing.Pens

Brushes

Pen SolidYellowPen = Pens.Yellow;

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

System.Drawing.Graphics

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

ScrollMoreShapes

ScrollShapes

System.Drawing.Drawing2D

using System;

using System.Drawing;

using System.Drawing.Drawing2D;

using System.Collections;

using System.ComponentModel;

using System.Windows.Forms;

using System.Data;

Используем несколько дополнительных полей в классе

Form1

private Rectangle rectangleBounds =

 new Rectangle(new Point(0, 0), new Size(200, 200));

private Rectangle ellipseBounds =

 new Rectangle(new Point(50, 200), new Size(200, 150));

private Pen BluePen = new Pen(Color.Blue, 3);

private Pen RedPen = new Pen(Color.Red, 2);

private Brush SolidAzureBrush = Brushes.Azure;

private Brush CrossBrush = new HatchBrush(HatchStyle.Cross, Color.Azure);

static private Brush BrickBrush =

 new HatchBrush(HatchStyle.DiagonalBrick, Color.DarkGoldenrod, Color.Cyan);

private Pen BrickWidePen = new Pen(BrickBrush, 10);

Поле

BrickBrush

BrickWidePen

Form1

OnPaint()

protected override void OnPaint(PaintEventArgs e ) {

 Graphics dc = e.Graphics;

 Point scrollOffset = this.AutoScrollPosition;

 dc.TranslateTransform(scrollOffset.X, scrollOffset.Y);

 if (e.ClipRectangle.Top+scrollOffset-X < 350 ||

     e.ClipRectangle.Left+scrollOffset.Y < 250) {

  dc.DrawRectangle(BluePen, rectangleBounds);

  dc.FillRectangle(CrossBrush, rectangleBounds);

  dc.DrawEllipse(RedPen, ellipseBounds);

  dc.FillEllipse(SolidAzureBrush, ellipseBounds);

  dc.DrawLine(BrickWidePen, rectangleBounds.Location,

   ellipseBounds.Location + ellipseBounds.Size);

 }

 base.OnPaint(e);

}

А это результат:

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

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

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

Image MyImage = Image.FromFile("FileName"!);

FromFile()

Image

.bmp

.jpg

.gif

.png

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

Graphics

dc.DrawImageUnscaled(MyImage, TopLeft);

В этой строке кода

dc

Graphics

MyImage

Image

TopLeft

Point

По всей вероятности, изображения являются областью, в которой разработчики знакомые с GDI, заметят наибольшие различия с GDI+. В GDI работа с изображениями была достаточно непредсказуемой. Вывод изображения включал несколько нетривиальных шагов. Если изображение задавалось как битовое, загрузка его была относительно простой, но загрузка любого другого типа файла включала последовательность вызовов объектов OLE. В действительности вывод загруженного изображения на экран включал получение для него дескриптора, выбор его в памяти контекста устройства и затем выполнение блочного переноса между контекстами устройств. Хотя контексты устройств и дескрипторы, по-прежнему находятся за сценой и понадобятся, если придется делать (ложное редактирование изображений в коде программы, простые задачи теперь погружены в объектную модель GDI+.

Мы проиллюстрируем процесс вывода изображения с помощью примера

DisplayImage

.jpg

.jpg

.jpg

Как обычно в этой главе, проект

DisplayImage

Form1

Image Piccy;

Затем загружаем файл в процедуру

InitializeComponent

private void InitializeComponent() {

 this.components = new System.ComponentModel.Container();

 this.Size = new System.Drawing.Size(600, 400);

 this.Text = "Display COMFEst Image";

 this.BackColor = Color.White;

 Piccy =

  Image.FromFile(@"C:\ProCSharp\Chapter21\Display Image\CF4Group.jpg");

 this.AutoScrollMinSize = Piccy.Size;

}

Отметим, что размер изображения в пикселях задается как его свойство

Size

OnPaint()

protected override void OnPaint(PaintEventArgs e) {

 Graphics dc = e.Graphics;

 dc.DrawImageUnscaled(Piccy, this.AutoScrollPosition);

 base.OnPaint(e);

}

Выбор

this.AutoScrollPosition

Наконец, сделаем еще одно замечание об изменениях, сделанных в коде метода

Form1.Dispose()

public override void Dispose() {

 base.Dispose();

 if (components != null) components.Dispose();

 Piccy.Dispose();

}

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

Image.Dispose()

Image

Выполнение этого кода создает результат:

COMFest (www.comfest.co.uk) является неформальной группой разработчиков в Великобритании, которые встречаются для обсуждения самых новых технологий, обмена идеями и т. д. Снимок включает всех участников COMFest 4, за исключением автора этой главы, который фотографировал.

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

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

Image.DrawImageUnscaled()

Метод

BitBlt

BitBlt

BitBlt()

BitBlt

Невозможно использовать

BitBlt

BitBlt

BitBlt

BitBlt

Graphics

DrawImage()

DrawImageUnscaled()

BitBlt

DrawImage()

BitBlt

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

Graphics

Graphics.DrawString()

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

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

Graphics.MeasureString()

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

CapsEditor

Пример является обычным результатом работы Windows Forms. В этот раз метод

OnPaint()

protected override void OnPaint(PaintEventArgs e) {

 Graphics dc = e.Graphics;

 Brush blackBrush = Brushes.Black;

 Brush blueBrush = Brushes.Blue;

 Font haettenschweilerFont = new Font("Haettenschweiler", 12);

 Font boldTimesFont = new Font("Times New Roman", 10, FontStyle.Bold);

 Font italicCourierFont = new Font("Courier", 11, FontStyle.Italic | FontStyle.Underline);

 dc.DrawString("This is a groovy string", haettenschweilerFont, blackBrush, 10, 10); 

 c.DrawString("This is a groovy string " +

  "with some very long text that will never fit in the box", boldTimesFont, blueBrush,

  new Rectangle(new Point(10, 40), new Size(100, 40)));

 dc.DrawString("This is a groovy string", italicCourierFont, blackBrush,

  new Point(10, 100)); base.OnPaint(e);

}

Выполнение этого примера создает вывод:

Этот пример демонстрирует использование метода

Graphics.DrawString()

DrawString()

Point

Rectangle

Point

Point

Rectangle

Graphics

rawString

DrawString()

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

Все интуитивно считают, что достаточно хорошо понимают шрифты. В конце концов мы видим их почти постоянно. Шрифт точно описывает, как должна выводиться каждая буква. Выбор подходящего шрифта, а также предоставление разумного множества шрифтов в документе является важным фактором улучшения читабельности документа. Можно просто взглянуть на страницы этой книги, чтобы увидеть, сколько использовалось шрифтов. Нужно тщательно выбирать шрифты, поскольку плохой выбор шрифта может существенно повредить как привлекательности, так и использованию приложения. Многие при вопросе о названии шрифта скажут что-нибудь типа 'Arial' или 'Times New Roman' или 'Courier'. Фактически это не шрифты вообще, это семейства шрифтов. Шрифты будут чем-нибудь типа Arial 9-point italic. Семейство шрифтов сообщает в общих терминах визуальный стиль текста и является ключевым фактором в общем представлении приложения. Большинство людей способны распознавать стили наиболее распространенных семейств шрифтов, даже если и не осознают этого. Шрифт добавляет дополнительную информацию, определяя размер текста, а также применение к тексту определенных модификаций. Например, будет ли это жирный, курсив или подчеркнутый текст, выведется ли он ЗАГЛАВНЫМИ БУКВАМИ или как _{подстрочный индекс}. Такие модификации технически называются стилями, хотя в некотором смысле термин вводит в заблуждение, поскольку только что было отмечено, что визуальное представление определяется в основном семейством шрифта.

Размер текста определяется его высотой. Высота измеряется в пунктах (points) — традиционная единица измерения, которая представляет 1/72 дюйма (для людей, живущих за пределами Великобритании и США, пункт равен 0.351 мм). Поэтому, например, буквы в 10-пунктовом шрифте имеют в высоту 10/72 дюйма (или приблизительно 1/7", или 3.5 мм). Из этого объяснения может показаться, что семь строк текста с размером шрифта 10 разместятся по вертикали на одном дюйме экрана или пространства бумаги. Фактически их будет немного меньше, так как необходимо также обеспечить интервалы между строками.

Строго говоря, измерение высоты не так просто, как может показаться, поскольку есть несколько различных высот, которые необходимо учитывать. Например, существует высота высокой буквы, такой как А или f (этот размер мы действительно имеем в виду, когда говорим о высоте), дополнительная высота, занимаемая любым акцентом над буквой типа Å или Ń (внутренняя высота строки), и дополнительная высота ниже базовой линии, необходимая для нижних частей букв типа у или g (спуск). Однако для данной главы это несущественно. Если определено семейство шрифтов и основная высота, такие дополнительные высоты задаются автоматически — нельзя независимо выбрать их значения.

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

□ Семейство шрифтов serif имеет небольшие черточки на концах многих линий, которые составляют символы. Эти черточки называют засечками (serifs). Times New Roman является классическим примером такого шрифта.

□ Семейства шрифтов sans serif, в противоположность, не имеют этих черточек. Хорошими примерами шрифтов sans serif являются Arial и Verdana. Отсутствие черточек часто придает тексту резкий, бросающийся в глаза вид, поэтому шрифты sans serif часто используются для выделения важного текста.

□ В семействе шрифтов true type очертания кривых, формирующих символы, вычисляются точными математическими способами. Это означает, что одно и то же определение может использоваться для вычисления того, как нарисовать шрифты семейства любого размера. Сегодня практически все используемые шрифты являются шрифтами true type. Некоторые старые семейства шрифтов из Windows 3.1 определялись с помощью отдельного битового изображения для каждого символа любого размера, но сегодня эти шрифты не используются. (Среди других недостатков они вызывают проблемы при переходе от экрана к современному принтеру, где число пикселей на дюйм значительно больше, поэтому битовые изображения будут выглядеть слишком маленькими).

Microsoft предоставляет два основных класса, с которыми необходимо иметь дело при выборе или манипуляциях со шрифтами. Это классы

System.Drawing.Font

System.DrawingFontFamily

Font

Font

DrawString

FontFamily

Одно из применений класса

FontFamily

GenericSerif

GenericSansSerif

GenericMonospace

FontFamily sansSerifFont = FontFamily.GenericSansSerif;

Однако при написании профессионального приложения желательно выбирать шрифт более тщательно. Скорее всего, код рисования реализуется таким образом, что будет проверять, какие семейства шрифтов реально установлены на компьютере и, следовательно, какие шрифты доступны. Затем приложение выберет подходящий шрифт, возможно, взяв первый доступный шрифт из списка предпочтительных шрифтов. Если желательно, чтобы приложение имело более дружественный пользовательский интерфейс, то первым вариантом в списке предпочтительных будет шрифт, который пользователь выбирал в последний раз при выполнении этого приложения. Обычно используются наиболее популярные семейства шрифтов, такие как Arial и Times New Roman. Но если попробовать вывести текст с помощью шрифта, который не существует, результаты не всегда будут предсказуемы, и, скорее всего, Windows просто подставит стандартный системный шрифт, который очень легко нарисовать системе, но который выглядит не совсем удачно и, появившись в документе, создаст впечатление программного обеспечения плохого качества.

Шрифты, доступные в системе, можно определить с помощью класса, называемого

InstalledFontCollection

System.Drawing.Text

Families

InstalledFontCollection insFonc = new InstalledFontCollection();

FontFamily [] families = insFont.Families;

foreach (FontFamily family in families) {

 // выполнить обработку с помощью этого семейства шрифтов

}

В этом разделе мы разберем небольшой пример

EnumFontFamilies

Отметим, однако, что в зависимости от установленных на компьютере шрифтов можно получить различные результаты. Для этого примера, как обычно, создается стандартное приложение C# для Windows с именем

EnumFontFamilies

Form1

const int margin = 10;

margin

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

InitializeComponent()

private void InitializeComponent() {

 this.components = new System.ComponentModel.Container();

 this.Size = new System.Drawing.Size(300, 300);

 this.Text = "EnumFontFamilies";

 this.BackColor = Color.White;

 this.AutoScrollMinSize = new Size(200, 500);

}

А вот метод

OnPaint()

protected override void OnPaint(PaintEventArgs e) {

 int verticalCoordinate = margin;

 Point topLeftCorner;

 InstalledFontCollection insFont = new InstalledFontCollection();

 FontFamily [] families = insFont.Families;

 e.Graphics.TranslateTransform(AutoScrollPosition.X, AutoScrollPosition.Y);

 foreach (FontFamily family in families) {

  if (family.IsStyleAvailable(FontStyle.Regular)) {

   Font f = new Font(family.Name, 10);

   topLeftCorner = new Point(margin, verticalCoordinate);

   verticalCoordinate += f.Height;

   e.Graphics.DrawString(family.Name, f, Brushes.Black, topLeftCorner);

   f.Dispose();

  }

  }

 base.OnPaint(e);

}

Этот код начинается с использования объекта

InstalledFontCollection

Font

Font f = new Font(family.Name, 10);

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

FontFamily

IsStyleAvailable()

if (family.IsStyleAvailable(FontStyle.Regular))

FontFamily.IsStyleAvailable()

FontStyle

OR

Bold

Italic

Regular

Strikeout

Underline

Наконец, отметим, что здесь используется свойство

Height

Font

Font f = new Font (family.Name, 10);

topLeftCorner = new Point(margin, verticalCoordinate);

VerticalCoordinate += f.Height;

Для упрощения кода используемая версия

OnPaint()

Font

OnPaint()

Dispose()

Мы переходим теперь к самому большому примеру этой главы. Пример

CapsEditor

Программа

CapsEditor

OnPaint()

Дадим обзор внешнего представления

CapsEditor

Меню File имеет два пункта: Open и Exit. Exit заканчивает приложение, в то время как Open выводит стандартное диалоговое окно для открытия файла и считывает файл, который выбирает пользователь. На снимке показано использование

CapsEditor

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

CapsEditor

Добавляем некоторые поля в класс

Form1

#region constant fields

private const string standardTitle = "CapsEditor";

// текст по умолчанию в заголовке

private const uint margin = 10;

// горизонтальное и вертикальное поля в клиентской области

#endregion

#region Member fields

private ArrayList documentLines = new ArrayList(); // "документ"

private uint lineHeight;   // высота одной строки в. пикселях

private Size documentSize; // какой требуется размер клиентской

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

private uint nLines;       // число строк в документе

private Font mainFont;     // шрифт, используемый для вывода

                           // всех строк

private Font emptyDocumentFont; // шрифт, используемый для вывода

                                // сообщения Empty

private Brush mainBrush = Brushes.Blue;

 // кисть, используемая для вывода текста документа

private Brush emptyDocumentBrush = Brushes.Red;

 // кисть, используемая для вывода сообщения empty document

private Point mouseDoubleClickPosition;

 // положение мыши при двойном щелчке

private OpenFileDialog fileOpenDialog = new OpenFileDialog();

 // стандартный диалог открытия файла

private bool documentHasData = false;

 // задать как true, если документ содержит данные

#endregion

Поле

documentLines

ArrayList

DocumentLines

ArrayList

#region

Как было сказано, каждый элемент

documentLines

TextLineInformation

class TextLineInformation {

 public string Text;

 public uint Width;

}

TextLineInformation

ArrayList

TextLineInformation

Каждый экземпляр

TextLineInformation

Width

Form1.lineHeight

Margin + LineHeight*(количество строк выше текущей строки)

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

Займемся теперь основным меню. Эта часть приложения принадлежит к формам Windows — тема рассмотрения главы 9. Пункты меню были добавлены с помощью графического представления в Visual Studio.NET, но переименованы как

menuFileOpen

menuFileExit

InitializeComponent()

private void InitializeComponent() {

 // добавлено мастером построения кода

 this.menuFileOpen = new System.Windows.Forms.MenuItem();

 this.menuFileExit = new System.Windows.Forms.MenuItem();

 this.mainMenu1 = new System.Windows.Forms.MainMenu();

 this.menuFile = new System.Windows.Forms.MenuItem();

 this.menuFileOpen.Index = 0;

 this.menuFileOpen.Text = "Open";

 this.menuFileExit.Index = 3;

 this.menuFileExit.Text = "Exit";

 this.mainMenu1.MenuItems.AddRange(new System.Windows.Forms.MenuItem[] {this.menuFile});

 this.menuFile.Index = 0;

 this.menuFile.MenuItems.AddRange(

  new System.Windows.Forms.MenuItem[] {this.menuFileOpen, this.menuFileExit});

 this.menuFile.Text = "File";

 this.menuFileOpen.Click +=

  new System.EventHandler(this, menuFileOpen_Click);

 this.menuFileExit.Click +=

  new System.EventHandler(this.menuFileExit_Click);

 this.AutoScaleBaseSize = new System.Drawing.Size(5, 13);

 this.BackColor = System.Drawing.Color.White;

 this.Size = new Size(600, 400);

 this.Menu = this.mainMenu1;

 this.Text = standardTitle;

 CreateFonts();

 FileOpenDialog.FileOk +=

  new System.ComponentModel.CancelEventHandler(this.OpenFileDialog_FileOk);

}

Мы добавили обработчики событий для пунктов меню File и Exit, а также для диалога FileOpen, который выводится, когда пользователь выбирает Open.

CreateFonts()

private void CreateFonts() {

 mainFont = new Font("Arial", 10);

 lineHeight = (uint)mainFont.Height;

 emptyDocumentFont = new Font("Verdana", 13, FontStyle.Bold);

}

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

protected void OpenFileDialog_FileOk(object Sender, CancelEventArgs e) {

 this.LoadFile(fileOpenDialog.FileName);

}

protected void menuFileOpen_Click(object sender, EventArgs e) {

 fileOpenDialog.ShowDialog();

}

protected void menuFileExit_Click(object sender, EventArgs e) {

 this.Close();

}

Исследуем метод

LoadFile()

Paint

private void LoadFile(string FileName) {

 StreamReader sr = new StreamReader(FileName);

 string nextLine;

 documentLines.Clear();

 nLines = 0;

 TextLineInformation nextLineInfo;

 while ((nextLine = sr.ReadLine()) != null) {

  nextLineInfo = new TextLineInformation();

  nextLineInfо.Text = nextLine;

  documentLines.Add(nextLineInfo); ++nLines;

 }

 sr.Close();

 documentHasData = (nLines > 0) ? true : false;

 CalculateLineWidths();

 CalculateDocumentSize();

 this.Text = standardTitle + " " + FileName;

 this.Invalidate();

}

Большая часть этой функции является просто стандартным кодом чтения файла (см. главу 14). Обратите внимание, что по мере чтения файла мы последовательно добавляем строки в

documentLines ArrayList

documentHasData

Invalidate()

Invalidate()

CalculateLineWidths()

CalculateDocumentSize()

Invalidate()

System.Windows.Forms.Form

Event

Invalidate()

Почему мы делаем это таким образом? Если мы знаем, что требуется что-то нарисовать, почему не вызвать просто

OnPaint()

Invalidate()

Для этого существует несколько причин:

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

LoadFile()

LoadFile()

Invalidate()

Paint

LoadFile()

Paint

OnPaint()

WM_QUIT

Invalidate()

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

Invalidate()

Application.Run()

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

Invalidate()

Paint

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

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

OnPaint()

Invalidate()

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

С<Имя_приложения>View

, который отвечал за это. Однако даже в таком случае этот класс имел функцию-член

OnDraw()

, которая была создана, чтобы быть точкой входа для большинства запросов рисования.

Мы возвращаемся теперь к примеру

CapsEditor

CalculateLineWidths()

CalculateDocumentSize()

LoadFile()

private void CalculateLineWidths() {

 Graphics dc = this.CreateGraphics();

 foreach (TextLineInformation nextLine in documentLines) {

  nextLine.Width = (uint)dc.MeasureString(nextLine.Text, mainFont).Width;

 }

}

Этот метод просто выполняется на каждой прочитанной строке и использует метод

Graphics.MeasureString()

MeasureString()

CapsEditor

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

private void CalculateDocumentSize() {

 if (!documentHasData) {

  documentSize = new Size(100, 200);

 } else {

  documentSize.Height = (int)(nLines*lineHeight) + 2*(int)margin;

  uint maxLineLength = 0;

  foreach (TextLineInformation nextWord in documentLines) {

   uint tempLineLength = nextWord.Width + 2*margin;

   if (tempLineLength > maxLineLength) maxLineLength = tempLineLength;

  }

  documentSize.Width = (int)maxLineLength;

 }

 this.AutoScrollMinSize = documentSize;

}

Этот метод сначала проверяет, есть ли данные для вывода. Если данных нет, мы слегка схитрим и зададим жестко кодированный размер документа такой величины, чтобы хватило места для выведения большими красными буквами предупреждения <Empty Document>. В противном случае необходимо воспользоваться методом

MeasureString()

После этого размер документа сообщается экземпляру класса Form, задавая свойство

Form.AutoScrollMinSize

Paint

Form.Invalidate()

LoadFile()

Invalidate()

Invalidate()

LoadFile()

Invalidate()

Paint

Invalidate()

Paint

Paint

Итак, мы увидели, как

CapsEditor

protected override void OnPaint(PaintEventArgs e) {

 Graphics dc = e.Graphics;

 int scrollPositionX = this.AutoScrollPosition.X;

 int scrollPositionY = this.AutoScrollPosition.Y;

 dc.TranslateTransform(scrollPositionX, scrollPositionY);

 if (!documentHasData) {

  dc.DrawString("<Empty Document>", emptyDocumentFont,

   emptyDocumentBrush, new Point(20, 20));

  base.OnPaint(e);

 return;

 }

 // определить, какие строки находятся в вырезанном прямоугольнике

 int minLineInClipRegion =

  WorldYCoordinateToLineIndex(е.ClipRectangle.Top - scrollPositionY);

 if (minLineInClipRegion == -1) minLineInClipRegion = 0;

 int maxLineInClipRegion =

  WorldYCoordinateToLineIndex(e.ClipRectangle.Bottom - scrollPositionY);

 if (maxLineInClipRegion >= this.documentLines.Count || maxLineInClipRegion == -1)

  maxLineInClipRegion = this.documentLines.Count - 1;

 TextLineInformation nextLine;

 for (int i = minLineInClipRegion; i <= maxLineInClipRegion; i++) {

  nextLine = (TextLineInformation)documentLines[i];

  dc.DrawString(nextLine.Text, mainFont, mainBrush, this.LineIndexToWorldCoordinates(i));

 }

base.OnPaint(e);

}

В середине этой перезагружаемой версии

OnPaint()

Graphics.DrawString()

Мы начинаем с проверки, имеются ли в документе какие-либо данные. Если данных нет, мы выводим краткое сообщение, говорящее об этом вызываем реализацию

OnPaint()

WorldYCoordinateToLineIndex()

При первом вызове метода

WorldYCoordinateToLineIndex()

е.ClipRectangle.Top - scrollPositionY

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

minLineInClipRegion

maxLineInClipRegion

for

WorldYCoordinateToLineIndex()

LineIndexToWorldCoordinates()

TranslateTransform()

В этом разделе мы рассматриваем реализацию вспомогательных методов, которые были использованы в примере

CapsEditor

WorldYCoordinateToLineIndex()

LineIndexToWorldCoordinates()

Первое.

LineIndexToWorldCoordinates()

private Point LineIndexToWorldCoordinates(int index) {

 Point TopLeftCorner =

  new Point((int)margin, (int)(lineHeight*index + margin));

 return TopLeftCorner;

}

Мы также используем метод, который делает приблизительно обратное преобразование в

OnPaint()

WorldYCoordinateToLineIndex()

private int WorldYCoordinateToLineIndex(int у) {

 if (у < margin) return -1;

 return (int)((y - margin)/lineHeight);

}

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

WorldYCoordinateToLineIndex()

private int WorldCocrdinatesToLineIndex(Point position) {

 if (!documentHasData) return -1;

 if (position.Y < margin || position.X < margin) return -1;

 int index = (int) (position.Y - margin) / (int) this.lineHeight;

 // проверить, что позиция находится не ниже документа

 if (index >= documentLines.Count) return -1;

 // теперь проверим, что горизонтальная позиция располагается

 // внутри строки

 TextLineInformation theLine =

  (TextLineInformation)documentLines[index];

 if (position.X > margin * theLine.Width)

 return -1;

 // все хорошо. Можно вернуть ответ.

 return index;

}

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

private Point LineIndexToPageCoordinates(int index) {

 return LineIndexToWorldCoordinates(index) + new Size(AutoScrollPosition);

}

private int PageCoordinatesToLineIndex(Point position) {

 return WorldCoordinatesToLineIndex(position - new Size(AutoScrollPosition));

}

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

До сих пор, за исключением пеню File в примере

CapsEditor

CapsEditor

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

Form

OnPaint()

Paint

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

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

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

MouseDown

MouseUp

Click

EventArgs

MouseEventArgs

X

Y

KeyEventArgs

KeyPressEventArgs

Затем разработчик должен продумать логику последующих действий. Только одно замечание. Вполне вероятно, что приложение GDI+ потребует создания большего объема логики, чем приложение

Windows.Forms

Windows.Forms

TextChanged

MouseDown

MouseMove

OnMouseUp()

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

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

Для примера

CapsEditor

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

Doubleclick

EventArgs

MouseEventArgs

MouseEventArgs

Control.MousePosition

Form1

protected override void OnDoubleClick(EventArgs e) {

 Point MouseLocation = Control.MousePosition;

 // обработать двойной щелчок

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

OnDoubleClick()

OnDoubleClick()

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

OnDoubleClick()

OnMouseDown()

OnMouseDown()

OnDoubleClick()

CapsEditor

protected override void OnMouseDown(MouseEventArgs e) {

 base.OnMouseDown(e);

 this.mouseDoubleClickPosition = new Point(e.X, e.Y);

}

Теперь посмотрим на перезагруженную версию

OnDoubleClick()

protected override void OnDoubleClick(EventArgs e) {

 int i = PageCoordinatesToLineIndex(this.mouseDoubleClickPosition);

 if (i >= 0) {

  TextLineInformation lineToBeChanged =

   (TextLineInformation) documentLines[i];

  lineToBeChanged.Text = lineToBeChanged.Text.ToUpper();

  Graphics dc = this.CreateGraphics();

  uint newWidth = (uint)dc.MeasureString(lineToBeChanged.Text, mainFont).Width:

  if (newWidth > lineToBeChanged.Width) lineToBeChanged.Width = newWidth;

  if(newWidth+2*margin > this.documentSize.Width) {

   this.documentSize.Width = (int)newWidth;

   this.AutoScrollMinSize = this.documentSize;

  }

  Rectangle changedRectangle =

   new Rectangle(

   LineIndexToPageCoordinates(i), new Size((int)newWidth, (int)this.lineHeight));

  this.Invalidate(changedRectangle);

 }

 base.OnDoubleClick(e);

}

Начнем работу с вызова

PageCoordinatesToLineIndex()

OnDoubleClick()

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

string.ToUpper()

Затем код использует

Graphics.MeasureString()

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

AutoScrollMinSize

□ Вторая: размер документа может не измениться.

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

Invalidate()

Invalidate()

Invalidate()

OnPaint()

OnPaint()

OnPaint()

PaintEventArgs

OnPaint

OnPaint()

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

Во многом печать схожа с выводом на экран. Предоставляется контекст устройства (экземпляр

Graphics

Grpahics.PageUnit

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

System.Drawing.Printing

PrintDialog

PrintPreviewDialog

System.Windows.Forms

Show()

В этой главе было рассмотрено рисование на устройстве вывода, реализующиеся в коде приложения, а не с помощью предопределенных элементов управления или диалоговых окон. GDI+ является мощным инструментом, и базовые классы .NET могут помочь при рисовании на устройстве. Мы видели, что этот процесс является в действительности довольно простым, в большинстве случаев можно рисовать текст и сложные фигуры или выводить изображения с помощью пары инструкций C#. Однако управление рисованием — работа, происходящая неявно, включающая определение, что и где нарисовать и нужна ли перерисовка в любой данной ситуации. Это значительно более сложная задача, требующая тщательного проектирования алгоритма. Важно хорошо понимать, как работает GDI+ и какие действия предпринимает Windows для рисования. В частности, с учетом архитектуры Windows важно, чтобы рисование выполнялось с помощью объявления областей окна недействительными, где это возможно, в таком случае система Windows реагирует должным образом на событие Paint.

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