4. Графические (не оконные) визуальные элементы

В этой главе будут кратко рассмотрены графические, т.е. без-оконные аналоги некоторых оконных объектов, не имеющие оконных дескрипторов. Как это ни покажется удивительным, но в KOL существует значительно более широкий спектр таких объектов, чем в VCL. Кроме метки и ящика для рисования, в библиотеке KOL даны графические аналоги так же для кнопки, флажков (check box) и радио-флажков (radio box), и даже для однострочного поля ввода (edit box).

Как известно, основное предназначение графических контролов заключается в снижении нагрузки на систему в случае, когда форма содержит очень большое число визуальных элементов. Например, если вы попытаетесь реализовать игру «Минер» для поля 50х50 клеток, изображая клетки обычными кнопками, то надо ожидать резкого падения производительности даже очень мощного компьютера при запуске такого приложения. (Разумеется, никто так не делает, этот пример довольно абстрактен).

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

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

В частности, это означает, что графические визуальные объекты предоставляют более богатый набор возможностей по модификации своего внешнего вида со стороны разработчика, нежели их оконные собратья. Например, обычная кнопка в Windows не позволяет изменить свой цвет или цвет шрифта своей надписи, и то же относится к флажкам, которые, по сути, так же являются кнопками. [Не знаю, честное слово, зачем нужно такое ограничение. Это приводит к тому, что программистский народ, пытаясь сделать свой интерфейс чуточку менее серым и однообразным, вместо стандартных кнопок начинает использовать саморисованные кнопки, а потом это все начинает выглядеть только хуже, когда включаются темы XP. В любом случае, этот вопрос следует задавать разработчикам операционной системы Windows].

Для графической кнопки такое ограничение на цвета не является актуальным. Кроме того, графические контролы в KOL имеют ряд дополнительных обработчиков событий, позволяющих вмешаться в процесс рисования на любом этапе процесса перерисовки, с тем, чтобы обеспечить желаемый внешний вид. А именно, кроме OnPaint, позволяющего заменить всю основную процедуру рисования, и OnEraseBkgnd, заменяющего процедуру стирания заднего плана, имеются так же OnPrePaint и OnPostPaint. Эти обработчики позволяют что-либо поправить до начала основного рисования (например, поменять стиль шрифта, или нарисовать некоторые части изображения и исключить их из области рисования), или поправить что-нибудь (выполнить надрисовки) после выполнения основного рисования.

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

В случае использования MCK, для того, чтобы оконный объект был заменен графическим, достаточно свойство Windowed установить в значение false. При этом, правда, следует не забыть добавить в свойства проекта символ условной компиляции USE_GRAPHCTLS, чтобы все необходимые объявления стали доступны компилятору (само по себе добавление этого символа даже без действительного использования графических контролов увеличивает размер приложения на сотню байтов).

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