Для организации локальной петли сообщений существует метод

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

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

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

Процедура

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

Примечание

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

TThread.Synchronize

с помощью

SendMessage

посылал этому окну сообщение

CM_EXECPROC

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

CheckSynchronize

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

TApplication

.

Принятый в Delphi 6 способ синхронизации получил дальнейшее развитие в BDS 2006. В классе TThread появился метод

Queue

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

Queue

, после этого продолжает работать, не дожидаясь, пока главная нить выполнит требуемый код. Главная нить выполняет этот код параллельно тогда, когда для этого предоставляется случай (информация получена из анализа исходных кодов модулей VCL, т.к. справка Delphi, к сожалению не описывает данный метод: в справке BDS 2006 он вообще не упомянут, в справке Delphi 2007 упомянут, но все описание состоит из одной фразы "This is Queue, а member of class TThread"). Метод

Queue

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

Synchronize

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

CheckSynchronize

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

Queue

. А метод

TThread.RemoveQueuedEvents

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

При показе VCL-формы в модальном режиме выборка сообщений из очереди осуществляется особым образом. Модальные окна в VCL — это не то же самое, что модальные диалоги с точки зрения API. Диалог может быть создан только на основе шаблона, и его модальность обеспечивается самой операционной системой, a VCL допускает модальность для любой формы, позволяя разработчику не быть ограниченным возможностями предусмотренного системой шаблона. Достигается это следующим образом: при вызове метода

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

Внутри

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

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

содержит недокументированную функцию , описанную так:

Тип

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

Функция

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

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

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