Симон Робинсон - C# для профессионалов. Том II

Почему мы делаем это таким образом? Если мы знаем, что требуется что-то нарисовать, почему не вызвать просто OnPaint()или другой метод? При необходимости сделать на экране очень точное небольшое изменение, можно так и поступить, но обычно вызов процедур рисования напрямую рассматривается как плохая практика программирования. Если код решает, что требуется выполнить некоторое рисование, обычно вызывается метод Invalidate().

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

□ Рисование почти всегда является наиболее интенсивно использующей процессор задачей, которую будет решать приложение GDI+. Выполнение его в середине другой работы задерживают эту работу. Для нашего примера, если бы метод рисования вызывался прямо из метода LoadFile(), то метод LoadFile()не вернул бы управление, пока не завершена задача рисования. В течение этого времени приложение не сможет ответить ни на одно иное событие. С другой стороны, вызывая метод Invalidate(), мы просто поручаем Windows инициировать событие Paintперед непосредственным выходом из LoadFile(). Система Windows тогда сможет проверить события, ожидающие обработки. Внутренне это происходит следующим образом. События находятся в так называемых сообщениях, которые выстраиваются в очередь. Система Windows периодически проверяет очередь сообщений, и если в ней есть события, Windows берет одно из них и вызывает соответствующий обработчик событий. С большой вероятностью событие Paint— единственное событие, находящееся в очереди, поэтому OnPaint()будет немедленно вызван в любом случае. Однако в более сложных приложениях могут быть другие события, некоторые из них имеют приоритет. В частности, если пользователь решил покинуть приложение, это будет отмечено сообщением в очереди, известном как WM_QUIT. Обработка такого события будет иметь самый высокий приоритет. Это очевидно, так как выполнение, например обновления графики в окне приложения, которое в данный момент будет закрыто, не имеет смысла. Таким образом, использование для рисования области метода Invalidate()сортировки запросов означает, что приложение действует, как хорошо ведущее себя приложение Windows.

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

□ Существует также причина, связанная с производительностью. Предположим, что примерно в одно время поступает пара различных запросов для рисования части экрана. Возможно, что код только что сделал изменение документа и хочет убедиться, что обновленный документ выводится, а в то же самое время пользователь восстановил минимизированное окно или переместил другое окно, которое закрывало часть клиентской области. Вызывая Invalidate(), мы даем знать окну, что это произошло. Windows может затем объединить события 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() {