О чём не пишут в книгах по Delphi

Григорьев Антон Борисович

Второй вопрос — зачем так сложно? Почему в методе

CreateWnd

сразу после создания окна нельзя было вызвать

SetWindowLong

и установить нужную оконную процедуру там, вместо того чтобы поручать это процедуре

InitWndProc

? Здесь ответ такой: это сделано потому, что свои первые несколько сообщений (например, сообщения

WM_CREATE

и

WM_NCCREATE

) окно получает до того, как функция

CreateWindowEx

завершит свою работу. Чтобы завершить создание окна,

CreateWindowEx

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

CreateWindowEx

— это

слишком поздно. Именно поэтому уникальная оконная процедура назначается таким неочевидным и несколько неуклюжим способом.

1.1.8. Обработка сообщений с помощью VCL

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

Кроме сообщений, предусмотренных в системе, компоненты VCL обмениваются сообщениями, созданными авторами этой библиотеки. Эти сообщения имеют префиксы

CM_

и

CN_

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

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

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

WS_EX_APPWINDOW

). Обычно в приложении одно окно главного уровня, и оно играет роль главного окна этого приложения, хотя система не запрещает приложению создавать несколько окон верхнего уровня (примеры — Internet Explorer, Microsoft Word). Разработчики VCL пошли по другому пути: окно верхнего уровня, ответственное за появление кнопки на панели задач, создается объектом

Application

. Дескриптор этого окна хранится в свойстве

Application.Handle

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

Application

и объекта главной формы внутри VCL. Таким образом, даже простейшее VCL-приложение создает два окна: невидимое окно объекта Application и окно главной формы. Окно, создаваемое объектом

Application

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

Parent

, в том числе и главной формы.

При обработке сообщений VCL решает две задачи: выборка сообщений из очереди и передача сообщения конкретному компоненту. Рассмотрим сначала первую задачу.

Выборкой сообщений из очереди занимается объект

Application

, непосредственно за извлечение и диспетчеризацию сообщения отвечает его метод

ProcessMessage

(листинг 1.13).

Листинг 1.13. Метод

TApplication.ProcessMessage

function TApplication.ProcessMessage(var Msg: TMsg): Boolean;

var

 Unicode: Boolean;

 Handled: Boolean;

 MsgExists: Boolean;

begin

 Result := False;

 if PeekMessage(Msg, 0, 0, 0, PM_NOREMOVE) then

 begin

Unicode := (Msg.hwnd <> 0) and IsWindowUnicode(Msg.hwnd);

if Unicode then MsgExists := PeekMessageW(Msg, 0, 0, 0, PM_REMOVE)

else MsgExists := PeekMessage(Msg, 0, 0, 0, PM_REMOVE);

if not MsgExists then Exit;

Result := True;

if Msg.Message <> WM_QUIT then

begin

Handled := False;

if Assigned(FOnMessage) then FOnMessage(Msg, Handled);

if not IsPreProcessMessage(Msg) and not IsHintMsg(Msg) and not Handled and

not IsMDIMsg(Msg) and not IsKeyMsg(Msg) and not IsDlgMsg(Msg) then

begin

TranslateMessage(Msg);

if Unicode then DispatchMessageW(Msg);

else DispatchMessage(Msg);

end;

end else FTerminate := True;

 end;

end;

В

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

PeekMessage

. Сначала эта функция вызывается с параметром

PM_NOREMOVE

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

IsWindowUnicode

производится проверка, использует ли окно-адресат кодировку ANSI или Unicode, и затем, в зависимости от этого, сообщение извлекается либо функцией

PeekMessage

, либо ее Unicode-аналогом

PeekMessageW

(о Unicode-аналогах функций см. разд. 1.1.12). При диспетчеризации сообщения также вызывается либо функция

DispatchMessage

, либо ее Unicode-аналог

DispatchMessageW

.

Если метод

ProcessMessage

с помощью

PeekMessage

извлекает из очереди сообщение

WM_QUIT

, то он устанавливает в

True

поле

FTerminate

и завершает свою работу. Обработка всех остальных сообщений, извлеченных из очереди состоит из следующих основных этапов (см. рис. 1.6):

1. Если назначен обработчик

Application.OnMessage

, сообщение передается ему. В этом обработчике можно установить параметр-переменную

Handle

в

True

, что означает, что сообщение не нуждается в дополнительной обработке.

2. Второй шаг —это предварительная обработка сообщения (вызов метода

IsPreProcessMessage

). Этот шаг появился только начиная с BDS 2006, в более ранних версиях его не было. Обычно предварительную обработку осуществляет то окно, которому предназначено это сообщение, но если окно-адресат не является VCL-окном, производится поиск VCL-окна по цепочке родителей. Кроме того, если какое-либо окно захватит ввод мыши, предварительную обработку сообщений будет осуществлять именно оно. Если оконный компонент, удовлетворяющий этим требованиям, найден, вызывается его метод

PreProcessMessage

, который возвращает результат логического типа. Если компонент вернул

True

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

3. Затем, если на экране присутствует всплывающая подсказка (hint), проверяется, должно ли пришедшее сообщение прятать эту подсказку, и если да, то она убирается с экрана (метод

IsHintMessage

). Список сообщений, которые должны прятать окно подсказки, зависит от класса этого окна (здесь имеется в виду класс VCL, а не оконный класс) и определяется виртуальным методом

THintWindow.IsHintMsg

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

IsHintMessage

возвращает

False

, то сообщение дальше не обрабатывается, но стандартная реализация этого метода всегда возвращает

True

.