Перед тем, как начать заниматься рисованием линий и фигур, отрисовкой текста или отображением изображений и управления ими с помощью GDI+, необходимо создать объект Graphics. Объект Graphics представляет собой поверхность рисования GDI+ и используется для создания графических изображений.
Существует два этапа работы с графикой:
- Создание объекта Graphics.
- Использование объекта Graphics для рисования линий и фигур, отрисовки текста или отображения изображений и управления ими.
Создание графического объекта
Графический объект можно создать несколькими способами.
Как создать графический объект
- Получите ссылку на графический объект как часть PaintEventArgs события формы или элемента управления Paint. Обычно ссылка на графический объект таким образом берется при создании кода рисования для элемента управления. Аналогичным образом можно также получить графический объект в качестве свойства PrintPageEventArgs при обработке события PrintPage для объекта PrintDocument. -или-
- Вызовите метод элемента управления или формы CreateGraphics, чтобы получить ссылку на объект Graphics, представляющий собой область рисования этого элемента управления или формы. Используйте этот метод, если необходимо нарисовать на форме или элементе управления, которые уже существуют. -или-
- Создайте объект Graphics из любого объекта, наследуемого от Image. Этот вариант подходит если вы хотите изменить уже существующее изображение. Необходимые действия будут более подробно описаны в следующих разделах.
PaintEventArgs в обработчике событий Paint
При программировании PaintEventHandler для элементов управления или PrintPage для объекта PrintDocument, графический объект предоставляется в качестве одного из свойств PaintEventArgs или PrintPageEventArgs.
Лучшие бесплатные графические редакторы
Получение ссылки на графический объект из PaintEventArgs в событии Paint
- Объявите объект Graphics.
- Назначьте переменную для ссылки на объект Graphics, переданный как часть PaintEventArgs.
- Введите код, чтобы нарисовать форму или элемент управления. В следующем примере показано, как ссылаться на объект Graphics из PaintEventArgs в событии Paint :
Private Sub Form1_Paint(sender As Object, pe As PaintEventArgs) Handles _ MyBase.Paint ‘ Declares the Graphics object and sets it to the Graphics object ‘ supplied in the PaintEventArgs. Dim g As Graphics = pe.Graphics ‘ Insert code to paint the form here. End Sub
private void Form1_Paint(object sender, System.Windows.Forms.PaintEventArgs pe) < // Declares the Graphics object and sets it to the Graphics object // supplied in the PaintEventArgs. Graphics g = pe.Graphics; // Insert code to paint the form here. >
private: void Form1_Paint(System::Object ^ sender, System::Windows::Forms::PaintEventArgs ^ pe) < // Declares the Graphics object and sets it to the Graphics object // supplied in the PaintEventArgs. Graphics ^ g = pe->Graphics; // Insert code to paint the form here. >
Метод CreateGraphics
Также можно воспользоваться методом элемента управления или формы CreateGraphics, чтобы получить ссылку на объект Graphics, представляющий собой область рисования этого элемента управления или формы.
300$ за неделю. Притворяюсь новичком в графическом дизайне, показываю схему, как ищу первых клиентов
Создание графического объекта с помощью метода CreateGraphics
- Вызовите метод CreateGraphics для формы или элемента управления, на которых требуется отрисовка графики.
Dim g as Graphics ‘ Sets g to a Graphics object representing the drawing surface of the ‘ control or form g is a member of. g = Me.CreateGraphics
Graphics g; // Sets g to a graphics object representing the drawing surface of the // control or form g is a member of. g = this.CreateGraphics();
Graphics ^ g; // Sets g to a graphics object representing the drawing surface of the // control or form g is a member of. g = this->CreateGraphics();
Создание из объекта изображения
Кроме того, можно создать графический объект из любого объекта, производного от класса Image.
Как создать графический объект на основе изображения
- Вызовите метод Graphics.FromImage, указав имя переменной изображения, из которой требуется создать объект Graphics. В приведенном ниже примере показано использование объекта Bitmap:
Dim myBitmap as New Bitmap(«C:Documents and SettingsJoePicsmyPic.bmp») Dim g as Graphics = Graphics.FromImage(myBitmap)
Bitmap ^ myBitmap = gcnew Bitmap(«D:\Documents and Settings\Joe\Pics\myPic.bmp»); Graphics ^ g = Graphics::FromImage(myBitmap);
Объекты Graphics можно создавать только из неиндексированных файлов формата .bmp, например 16-разрядных, 24-разрядных и 32-разрядных. Каждый пиксель неиндексированных файлов .bmp содержит цвет. В индексированных .bmp файлах же каждый пиксель содержит индекс таблицы цветов.
Рисование и обработка фигур и изображений
Объект Graphics после создания может использоваться для рисования линий и фигур, отрисовки текста или отображения изображений и управления ими. Вот основные объекты, которые используются с объектом Graphics:
- Класс Pen — используется для рисования линий, структурирования фигур или отрисовки других геометрических представлений.
- Класс Brush — используется для заполнения областей графики, в частности для заполненных фигур, изображений или текста.
- Класс Font — предоставляет собой описание фигур, используемых при отрисовке текста.
- Структура Color — представляет различные отображаемые цвета.
Использование созданного графического объекта
- Обратитесь к соответствующему объекту, указанному выше, чтобы нарисовать необходимые объекты. Дополнительные сведения см. в следующих разделах:
ОтрисовкаСм. Линии Практическое руководство. Рисование линии в Windows Forms Фигуры Практическое руководство. Рисование линии или контурной фигуры Текст Практическое руководство. Отрисовка текста в Windows Forms Изображения Практическое руководство. Отрисовка изображений с использованием GDI+
См. также раздел
- Приступая к программированию графики
- Объекты Graphics и Drawing в Windows Forms
- Прямые и кривые линии и фигуры
- Практическое руководство. Отрисовка изображений с использованием GDI+
Источник: learn.microsoft.com
7.4. Графическое приложение
В предыдущем разделе мы увидели, как просто создаются консольные приложения на ассемблере под Windows. Однако основными приложениями в Windows являются графические оконные приложения. Мы уже рассматривали создание простого окна сообщения с помощью единственной API-функции MessageBox. Однако построение стандартных окон приложений Windows, таких как на рис.
7.2, намного сложнее и одной API-функцией уже не обойтись. Рис. 7.2. Простейшее оконное графическое приложение
Прежде чем перейти к программированию стандартного окна, необходимо понять принципы работы графических приложений в Windows.
| http://www.sklyaroff.ru | 159 |
Функционирование ОС Windows основано на сообщениях. Сообщение — это небольшой пакет данных, который генерируется в результате определенного произошедшего события в системе. Например, после нажатия пользователем клавиши на клавиатуре, щелчка или перемещения указателя мыши, изменения размера окна, выбора пункта меню, перемещении бегунка прокрутки и т. д. Сообщения могут генерироваться системным таймером и самой Windows, например, в случае завершения работы системы Windows посылает каждому открытому окну сообщение о необходимости проверить сохранность данных и закрыть окна. Существуют тысячи различных видов сообщений, но все они представлены следующей структурой (определена в winuser.h):
| typedef struct tagMSG | // msg |
| HWND hwnd; | |
| UINT message; | |
| WPARAM wParam; | |
| LPARAM lParam; | |
| DWORD time; | |
| POINT pt; | |
| > MSG; |
Параметры: hwnd — дескриптор окна, которому адресуется сообщение; message — тип Windows-сообщения (например WM_RBUTTONDOWN – нажатие правой кнопки мыши). Имена всех типов сообщений начинаются с приставки WM_; wParam — параметр сообщения, содержащий дополнительные сведения о сообщении, например координаты указателя мыши; lParam — параметр сообщения, содержащий дополнительные сведения о сообщении; time — время постановки сообщения в очередь; pt — координаты мыши в момент time. На ассемблере эта структура с помощью неизученной пока нами директивы STRUC будет выглядеть следующим образом:
| MSG STRUCT | ||
| hwnd | DWORD | ? |
| message | DWORD | ? |
| wParam | DWORD | ? |
| lParam | DWORD | ? |
| time | DWORD | ? |
| pt | DWORD | ? |
| MSG ENDS |
В таком виде эта структура определена в файле WINDOWS.INC. Чтобы использовать поля этой структуры в программе нужно с помощью директивы INCLUDE подключить файл WINDOWS.INC и в сегменте данных сделать следующее определение: msg MSG Знак вопроса означает, что все поля структуры будут инициализированы неизвестным значением, но можно, например, инициализировать их нулем: msg MSG Доступ к отдельным полям осуществляется с помощью точки: mov msg.hwnd, EAX ; запись значения из EAX в поле hwnd mov msg.lParam, EAX ; запись значения из EAX в поле lParam
| http://www.sklyaroff.ru | 160 |
Всего существует четыре основных источника, от которых приложение может получать сообщения: пользователь, ОС Windows, само приложение (от самого себя), другие приложения. Все сообщения независимо от того, чем они сгенерированы и какому приложению предназначены, первоначально помещаются в так называемую системную очередь сообщений Windows.
Windows выполняет обработку некоторых сообщений самостоятельно, однако большая их часть передается для обработки приложениям. Следовательно, для того чтобы приложение смогло обрабатывать сообщения в нем должна быть организована локальная очередь сообщений. Приложение должно периодически проверять свою локальную очередь на наличие новых сообщений и выполнять их обработку.
Для этого в приложении необходимо организовать цикл и создать функцию для обработки поступающих сообщений. Существует два типа сообщений: синхронные и асинхронные. Очередь синхронных сообщений формируется по принципу FIFO (first in, first out — первым прибыл, первым обслужен). Асинхронные сообщения Windows всегда вставляет сразу в голову очереди.
Например, сообщения о перерисовке окна, сообщения таймера и сообщения о завершении программы являются асинхронными. Они имеют наивысший приоритет и всегда передаются раньше всех других сообщений. Это справедливо как для системной очереди сообщений, так и для локальных очередей приложений, т. к. локальные очереди формируются от системной очереди. Таким образом, полноценное графическое приложение будет состоять из следующих основных частей: регистрация класса окон; создание окна; цикл обработки очереди сообщений; процедура главного окна. Рассмотрим каждую часть графического приложения, а полный исходный код показан в листинге 7.4.
7.4.1. Регистрация класса окон
Класс окна это комбинация свойств окна, дескрипторы значка и указателя мыши, а также прочие атрибуты, которые будут являться шаблоном для всех экземпляров окон приложения. Класс регистрируется с помощью API-функции RegisterClass, которая имеет только один аргумент – указатель на структуру типа WNDCLASS. Структура WNDCLASS хранит характеристики создаваемого класса, поэтому перед регистрацией необходимо заполнить поля этой структуры. typedef struct < UINT style; WNDPROC lpfnWndProc; int cbClsExtra; int cbWndExtra; HINSTANCE hInstance; HICON hIcon; HCURSOR hCursor; HBRUSH hbrBackground; LPCTSTR lpszMenuName; LPCTSTR lpszClassName; >WNDCLASS, *PWNDCLASS; Параметры: style — определяет свойства окна. Все идентификаторы свойств окна начинаются с приставки CS_ (ищите их полный перечень в MSDN). Можно задать комбинацию свойств; lpfnWndProc — указатель на оконную процедуру, которая будет обрабатывать сообщения, получаемые окном;
| http://www.sklyaroff.ru | 161 |
cbClsExtra — количество байт, резервируемых в памяти после создания структуры класса окна. Может быть равным NULL; cbWndExtra — количество байт, резервируемых в памяти после создания экземпляра окна. Может быть равным NULL; hInstance — дескриптор экземпляра приложения, регистрирующего класс окна; hIcon — дескриптор иконки, которая будет символом окна данного класса.
Все идентификаторы предопределенных иконок начинаются с приставки IDI_. Этот параметр может быть равным NULL; hCursor — дескриптор указателя мыши, используемого в окне приложения. Все идентификаторы предопределенных курсоров начинаются с приставки IDC_ (вероятно «IDentificator of Cursor»).
Этот параметр может быть равным NULL; hbrBackground — дескриптор кисти (brush), которой будет закрашен фон окна; lpszMenuName — указатель на строку, завершающуюся нулевым символом и содержащую имя меню для данной программы. Если программа не работает с меню, то этот параметр может быть NULL; lpszClassName — указатель на строку, завершающуюся нулевым символом и содержащую имя создаваемого класса окна. Существует расширенный вариант структуры WNDCLASS, получивший название WNDCLASSEX: typedef struct < UINT cbSize; UINT style; WNDPROC lpfnWndProc; int cbClsExtra; int cbWndExtra; HINSTANCE hInstance; HICON hIcon; HCURSOR hCursor; HBRUSH hbrBackground; LPCTSTR lpszMenuName; LPCTSTR lpszClassName; HICON hIconSm; >WNDCLASSEX, *PWNDCLASSEX; От WNDCLASS он отличается наличием двух дополнительных полей: cbSize — задает размер всей структуры; hIconSm — содержит дескриптор малого значка. В файле WINDOWS.INC структура WNDCLASSEX определена следующим образом:
| WNDCLASSEX STRUCT | ||
| cbSize | DWORD | ? |
| style | DWORD | ? |
| lpfnWndProc | DWORD | ? |
| cbClsExtra | DWORD | ? |
| cbWndExtra | DWORD | ? |
| hInstance | DWORD | ? |
| hIcon | DWORD | ? |
| hCursor | DWORD | ? |
| hbrBackground | DWORD | ? |
| lpszMenuName | DWORD | ? |
| lpszClassName | DWORD | ? |
| hIconSm | DWORD | ? |
| WNDCLASSEX ENDS |
Источник: studfile.net
Как программу оформить графически
В статье затронута проблема организации работы с объектами графического типа при разработке пользовательских приложений. Автором рассмотрены особенности взаимодействия графических объектов при программировании приложений на форме. Обсуждаются возможности программной реализации математических подходов средствами среды объектно-ориентированного программирования.
На примере игрового приложения DX-Ball проанализированы программные аспекты реализации взаимодействия графических элементов на форме при организации движения в среде Lazarus. На основании проведенного анализа автором предложено корректное решение реализации физики взаимодействия шарика с остальными графическими объектами на форме. А именно предложена программная реализация изменения положения шарика при его соударении с блоками и границами формы как графическими элементами. В завершении статьи охарактеризованы иные проблемы, которые возникают при работе с графикой на форме при разработке пользовательских приложений в объектно-ориентированных средах программирования.
информатика
программирование
информационно-коммуникационные технологии
пользовательское приложение
объектно-ориентированное программирование
1. Ковалева И. В., Баженов Р. И. Разработка двухмерной игры в системе трехмерного моделирования UNITY3D // Перспективные информационные технологии (ПИТ 2017): сборник трудов международной научно-технической конференции. – 2017. – С. 790-792.
2. Козлов С. В. Интерпретация инвариантов теории графов в контексте применения соответствия Галуа при создании и сопровождении информационных систем // International Journal of Open Information Technologies. – 2016. – Т. 4. № 7. – С. 38-44.
3. Козлов С. В. Применение методов функционального анализа при формировании оптимальных стратегий обучения школьников // Международный журнал экспериментального образования. – 2016. – № 3-2. – С. 182-185.
4. Козлов С. В. Система индивидуального тестирования «Комплекс измерения обученности» // Системы компьютерной математики и их приложения. – Смоленск: СмолГУ, 2007. – С. 223-225.
5. Козлов С.В. Функциональные назначения и возможности информационно-образовательного ресурса «ADVANCED TESTER» // Горизонты науки. – 2011. – № 2. – С. 9.
6. Максимова Н. А. Разработка приложений на основе сервис-ориентированных систем // NovaInfo.Ru. – 2016. – Т. 3. № 46. – С. 41-44.
7. Размахнина А. Н., Баженов Р. И. О применении экспертных систем в различных областях // Постулат. – 2017. – № 1 (15). – С. 38.
8. Сенчилов В. В. Возможности программного обеспечения при дистанционном обучении математике детей с особыми образовательными потребностями / Сенчилов В. В., Быков А. А., Киселева О. М., Тимофеева Н. М. // Евразийское Научное Объединение. – 2017. – Т. 2. № 8 (30). – С. 111-112.
9. Тимофеева Н. М., Киселева О. М. О применении программных средств в процессе обучения // Системы компьютерной математики и их приложения. – Смоленск: Изд-во СГПУ, 2005. – С. 233-235.
В настоящее время современные объектно-ориентированные среды программирования предоставляют пользователю широкий выбор инструментов по разработке проектов различного типа. Программист может создавать как стандартные консольные приложения, проекты на форме, так и достаточно узконаправленные приложения, например, текстовое приложение FCPUnit или программы InstantFPC.
В тоже время в независимости от типа проекта каждый из них должен отвечать ряду базовых принципов. Одним из таких важнейших принципов является принцип наглядности, в соответствии с которым информация представленная в проекте должна легко зрительно восприниматься любым пользователем. Особенно это важно в программных продуктах социальной направленности [8] и обучающих программных средствах [9]. Высокая степень зрительного восприятия достигается в программных продуктах за счет графических элементов интерфейса и диалоговых компонентов программных продуктов.
Как известно в объектно-ориентированных средах программирования очень большое внимание уделяется работе с графическими объектами, а также процессу взаимодействия с ними. Большинство современных приложений представляют собой проекты на форме, на которой могут быть одновременно размещены графические объекты различного класса [4]. Например, программист может помещать нужные ему изображения в такие объекты как:
— TBitBtn – кнопка, на которую можно нанести изображение;
— TImage – объект, предназначенный непосредственно для помещения изображения на форму;
— задний фон формы при помощи функции self.canvas.draw (рис. 1).
Рис. 1. Графические элементы в среде Lazarus
Подобного рода объекты существуют в каждой современной объектно-ориентированной среде программирования. Это позволяет разрабатывать приложения с качественным графическим интерфейсом. Для этого можно использовать как более простые, так и более мощные программные среды. От сред программирования MS Visual Studio и Embarcadero Studio до бесплатно распространяемой среды разработок программного обеспечения Lazarus.
В тоже время, несмотря на возможности используемой объектно-ориентированной среды программирования, наличие большого количества объектов на форме может негативно сказаться на производительности приложения. В качестве примера можно привести игровое приложение DX-Ball. Цель компьютерной игры состоит в том, чтобы, управляя движением шарика на поле, разбить им все имеющиеся блоки (рис. 2).
Рис. 2. Схематические изображение DX-Ball
Если размещать каждый блок на форме, как отдельный объект класса Image, то это обернется не только большой нагрузкой на ресурсы компьютера, но и необходимостью прописывать внутри программы избыточно большое количество повторяющегося программного кода. В связи с этим предложим один из вариантов решения данной проблемы, которая возникла при реализации проекта DX-Ball в объектно-ориентированной среде разработок Lazarus.
В начале производится расчет количества блоков, которое может быть помещено на имеющуюся форму по горизонтали и вертикали. В примере на рисунке 3 число блоков по горизонтали равно восемнадцати, а по вертикали равно восьми. Таким образом, с помощью рядов блоков построчно задают изображение (рис. 3).
Рис. 3. Число блоков на экране
На основе данной информации создается двумерный массив, размером восемнадцать на восемь. В дальнейшем эта матрица и будет являться «блоками» на экране. По умолчанию все элементы данной матрицы являются единицы.
При запуске программы соответствующая процедура последовательно «рисует» на форме восемнадцать блоков, начиная с левого верхнего угла. Далее программа переходит на следующий ряд и вызывает процедуру снова. Так повторяется восемь раз. Таким образом, ни один блок не является графическим объектом, по сути это просто задний фон формы.
Возникает логичный вопрос: «Каким образом происходит взаимодействие графического объекта «шарик» с блоками?» Именно с этой целью и был создан двумерный массив восемнадцать на восемь, исходно заполненный одними единицами. Каждый раз когда объект шарика попадает в ту часть формы, в которой могут находиться блоки (расстояние равное восемь умноженное на число рядов блоков пикселей от верха формы) программа начинает определять, на месте какого элемента начальной матрицы сейчас находится шарик. Если на соответствующей позиции в матрице стоит единица, значит, в данный момент происходит процесс столкновения шарика с блоком.
Такое стечение обстоятельств «провоцирует» выполнение следующей части программы. Траектория шарика изменяется, соответствующий элемент матрицы заменяется нулевым значением. На место, где раньше был блок, помещается новое изображение блока соответствующего размера, одного цвета с цветом заднего фона формы.
Также общее число оставшихся блоков, которое для удобства игрока всегда отображается на небольшой соседней форме, уменьшается на единицу. Игра заканчивается, когда это число достигнет нуля. Таким образом, существующий объект (шарик) взаимодействует не с подобными себе объектами, а с элементами двумерной матрицы, в прямом взаимодействии с которой находятся изображения на заднем фоне формы.
Приведем алгоритмическое решение описанных действий средствами объектно-ориентированной программной среды Lazarus (рис. 4).
Рис. 4. Часть кода процедуры столкновения шарика с блоком
Безусловно представленное решение рассматриваемой проблемы обладает, как и всякое другое решение, определенными достоинствами, так и недостатками. Главным достоинством программы можно считать упрощенную процедуру написания программного кода. Также к плюсам можно отнести сведение к минимуму количества графических элементов на форме.
К недостаткам, характерным для многих приложений подобного рода, прежде всего, относится некорректное взаимодействие шарика с блоками. Дело в том, что шарик «не видит», с какой частью блока он сталкивается. По законам логики и физики – в случае столкновения с верхней или нижней гранью шарик должен отскакивать в противоположную сторону по горизонтали. В случае же столкновения с одной из боковых сторон, он должен отскакивать в противоположную сторону по вертикали. В данной игре шарик «распознает» сам факт столкновения и всегда отскакивает по горизонтали.
Другой проблемой является процесс обновления блоков. Как уже было описано ранее – все блоки являются не более чем набором цветных пикселей на форме. Из-за этого, когда шарик «проходит» по картинке блока, но не разрушает его, он стирает часть этого блока (рис. 5).
Рис. 5. Пример частичного «стирания» блоков
Последнюю проблему частично удалось решить написанием процедуры, которая каждые несколько секунд перерисовывает не разрушенные блоки (рис. 6).
Рис. 6. Процедура перерисовки не разрушенных блоков
Все перечисленные недостатки могут быть математически, а, следовательно, и программно решены. Так, например, возможно применить в решении методы функционального анализа [3], инварианты теории графов [2] или методы теории экспертных систем [7].
Использование того или иного метода предопределяет общая цель разработки программного средства и требования, которые предъявляются к нему заказчиком. Они, определяют направления для дальнейшего совершенствования программы.
Подчеркнем, что программное решение можно осуществить не только средствами объектно-ориентированных сред программирования, но в специализированных системах моделирования, например, UNITY3D [1] или Advanced Tester [5]. Также возможно использование средств сервис-ориентированных систем [6]. Решение, приведенное в данной статье, демонстрирует наличие различных способов взаимодействия с графическими элементами посредством программного кода в объектно-ориентированных средах программирования. В завершение заметим, что для анализа ситуации с графическими объектами на форме проекта можно применить и иные методологии математического моделирования и универсальных программных решений.
Источник: eduherald.ru