5.6. Диалог выбора цвета (tColorDialog)

На вкус и цвет приятеля нет. (Русская народная пословица)

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

Конструктор:

NewColorDialog( fillopen ) - создает объект для вызова диалога цвета, возвращая указатель типа PColorDialog. Параметр fullopen задает, будет ли диалог сразу открываться "полностью", с дополнительным полем для выбора произвольного цвета True Color (16 миллионов цветов), или только в сокращенном виде.

Единственный метод объекта:

Execute - вызывает диалог на экран, и в случае успешного выбора цвета, сигнализирует об этом, возвращая значение true. Результат выбора следует считывать из поля Color объекта, после возврата из метода Execute.

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

OwnerWindow - окно, "владеющее" диалогом (становится активным немедленно после завершения диалога, так же используется для определения места на экране для размещения диалога в момент его открытия);

CustomColors[ 1..16 ] - дополнительные 16 цветов, которые помещаются в дополнительные квадратики в нижней части диалога. По умолчанию, все эти квадратики белые, и в самом диалоге пользователь может добавить в них свои цвета, используя расширение формы, где можно выбрать произвольный цвет RGB;

ColorCustomOption - дополнительный режим работы (открыть полностью, открыть сокращенно, не допускать открыть полностью);

Color - цвет, выбранный пользователем в результате успешного завершения диалога, типа TColor.

Зеркало в MCK: TKOLColorDialog.

5.7. Часы (tTimer)

Настало время поговорить о счете времени. Как и в VCL, для этого в KOL имеется объект TTimer. Он, при своей активации, создает системный объект, который регулярно вызывает назначенный обработчик таймера. Фактически, такой таймер привязывается к одному из окон: по умолчанию – к специально создаваемому для всех таймеров главного потока окну, или, если в приложении задан символ TIMER_APPLETWND, то к окну апплета (или главной формы, если апплет не задействован).

Для чего я все это пишу. Во-первых, из сказанного ясно, что никаких гарантий того, что такие часы будут "тикать" с высочайшей точностью, нет. Промежутки времени между вызовами обработчика события, назначенного таймеру, могут оказаться далеко не безупречно одинаковыми. И это существенно зависит, в том числе, от быстродействия системы, от степени ее загруженности различными задачами, от затребованного периода срабатывания. В частности, такой таймер, вряд ли сможет срабатывать чаще, чем один раз в 50 миллисекунд, т.е. чаще, чем 20 раз в секунду (1 миллисекунда = 0,001 секунды, т.е. в секунде заключено 1000 миллисекунд, если кто забыл).

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

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

О

братите внимание, что если в случае многопоточного приложения первый таймер «запускается» (установкой его свойства Enabled в значение TRUE) не в контексте основного потока, и символ условной компиляции TIMER_APPLETWND не определен в проекте, то специальное окно TimerOwnerWnd, «владеющее» таймером, окажется созданным в контексте текущего, т.е. не основного, потока. В результате, если в этом потоке нет работающего цикла обработки сообщений, ваши таймеры никогда не сработают. Это очень редкое сочетание условий мне как-то «повезло» получить, после чего пришлось долго ломать голову, что же не так. В моем случае проблема было решена добавлением символа TIMER_APPLETWND, но в принципе, ее можно решить, сразу запустив (и остановив, если не очень нужен) какой-нибудь пробный таймер в главном потоке, например, в обработчике OnFormCreate.

Замечу так жк, что для обеспечения минимальности кода, для создания такого окна используется вызов _NewWindowed, и по этой причине окно не является чистым окном для приема только сообщений. Оно становится так называемым topmost окном, и может принимать широковещательные сообщения. В случае наличия в приложении отдельного объекта Applet и установки в нем обработчика OnMessage, этот обработчик будет получать, в том числе, и все сообщения, предназначенные для этого невидимого окна. Это означает, в частности, что широковещательные сообщения системы будут перехватываться на один раз больше, чем у вас имеется форм в приложении. Вывод: анализируйте поле handle приходящего сообщения, чтобы узнать, какому окну оно предназначено, если это требуется.

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

Конструктор "часов":

NewTimer( i ) - создает объект TTimer с интервалом i миллисекунд, возвращая указатель типа PTimer. Первоначально таймер создается неактивным. Для его запуска требуется установить его свойство Enabled в значение true.

Свойства, методы и событие таймера:

Handle - дескриптор системного объекта hTimer, т.е. число, которое позволяет идентифицировать этот объект системой в запросах API низкого уровня. Этот дескриптор содержит значение 0, если таймер в данный момент неактивен (системный объект создается только при запуске таймера);

Enabled - активность таймера. Это свойство можно использовать, чтобы запустить или перезапустить таймер (для перезапуска необходимо часы сначала остановить, т.е. присвоить свойству Enabled значение false);

Interval - интервал срабатывания таймера. При изменении данного значения, когда объект активен, происходит "сброс" таймера, т.е. системный объект пересоздается, и отсчет времени до очередного срабатывания начинается заново;

OnTimer - событие таймера. В обработчике события разрешается изменять любые свойства объекта таймера, в том числе интервал, или состояние активности. Например, чтобы таймер срабатывал однократно, а не регулярно, в обработчик следует добавить код, присваивающий значение false свойству Enabled.

В пакете MCK для объекта TTimer имеется зеркальный компонент TKOLTimer. Но он позволяет генерировать код не только для простого объекта часов. Когда был разработан объект мультимедийного таймера, я решил задействовать этот же зеркальный компонент и для генерации его кода, тем более, что объекты TTimer и TMMTimer весьма похожи (см. ниже). В результате, зеркало TKOLTimer обогатилось некоторым количеством свойств, которые при генерации кода для обычного таймера использованы быть не могут, и попросту игнорируются, а именно: Periodic, Resolution.