А. Григорьев - О чём не пишут в книгах по Delphi
- Название:О чём не пишут в книгах по Delphi
- Автор:
- Жанр:
- Издательство:БХВ-Петербург
- Год:2008
- Город:СПб
- ISBN:978-5-9775-019003
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
А. Григорьев - О чём не пишут в книгах по Delphi краткое содержание
Рассмотрены малоосвещённые вопросы программирования в Delphi. Описаны методы интеграции VCL и API. Показаны внутренние механизмы VCL и приведены примеры вмешательства в эти механизмы. Рассмотрено использование сокетов в Delphi: различные механизмы их работы, особенности для протоколов TCP и UDP и др. Большое внимание уделено разбору ситуаций возникновения ошибок и получения неверных результатов в "простом и правильном" коде. Отдельно рассмотрены особенности работы с целыми, вещественными и строковыми типами данных, а также приведены примеры неверных результатов, связанных с ошибками компилятора, VCL и др. Для каждой из таких ситуаций предложены методы решения проблемы. Подробно рассмотрен синтаксический анализ в Delphi на примере арифметических выражений. Многочисленные примеры составлены с учётом различных версий: от Delphi 3 до Delphi 2007. Прилагаемый компакт-диск содержит примеры из книги.
Для программистов
О чём не пишут в книгах по Delphi - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Line2.Free;
Проанализируем, что происходит при выполнении этого кода. Для простоты предположим, что других компонентов, перехватывающих сообщения, здесь нет, и перед выполнением этого кода Form1.WindowProc
ссылается на Form1.WndProc
, т.е. на собственный обработчик сообщений формы. При создании объекта Line1
он перехватывает обработчик, и Form1.WindowProc
начинает ссылаться на Line1.HookOwnerMessage
, а ссылка на Form1.WndProc
сохраняется в Line1.FOldProc
. Объект Line2
также перехватывает обработчик сообщений, и после его создания Form1.WindowProc
будет ссылаться на Line2.HookOwnerMessage
, a Line2.FOldProc
— на Line1.HookOwnerMessage
.
Теперь удалим Line1
. При удалении объект восстановит ссылку на тот обработчик сообщений, который был установлен на момент его создания, т.е. Form1.WindowProc
вновь станет указывать на Form1.WndProc
. Соответственно, компонент Line2
потеряет способность реагировать на сообщения владельца. Поле Line2.FOldProc
при этом останется без изменений. Но самое неприятное начнется при удалении объекта Line2
. Он тоже восстановит ссылку на обработчик, который был назначен на момент его создания, т.е. запишет в свойство Form1.WindowProc
ссылку на Line1.HookOwnerMessage
. Но поскольку объекта Line1
уже не существует, это будет ссылка в никуда, и обработка первого же сообщения, пришедшего форме, даст ошибку Access violation.
Аналогичная проблема возникнет и в режиме проектирования, если на форму положить два компонента TLine
, удалить первый, a затем — второй. В этом случае ошибки возникнут в самой среде Delphi
, и ее придется перезапускать. Вообще говоря, компоненты, перехватывающие сообщения владельца, должны делать это только во время выполнения программы, чтобы не "уронить" среду. Здесь мы для наглядности опустили соответствующие проверки.
Проблема не возникает, если удалять объекты в порядке, обратном порядку их создания. Но в общем случае это не может быть решением проблемы, т.к. объекты должны создаваться и удаляться в том порядке, который требуется логикой работы программы. Соответственно, единственное решение — все перехватывающие сообщения владельца компоненты должны знать друг о друге и уведомлять друг друга о своем создании и удалении. Но и этот способ не дает полной гарантии. Пока один разработчик пишет компонент или библиотеку компонентов, он может обеспечить взаимодействие всех экземпляров компонентов в программе. Но если в одной программе будут использованы две такие библиотеки от разных разработчиков, они так же будут конфликтовать друг с другом, и универсального решения проблемы, судя по всему, не существует. Пользователю библиотек остается только соблюдать порядок удаления компонентов. Но, с другой стороны, есть ряд задач, в которых без перехвата сообщений владельца не обойтись, поэтому иногда приходится идти на это.
1.2.3. Пример CoordLabel
CoordLabel — это пример визуального компонента, перехватывающего сообщения своего родителя. Компонент TCoordLabel
отслеживает нажатие левой кнопки мыши на своем родителе и отображает координаты точки, в которой произошло нажатие. Для перехвата сообщений родителя используется тот же способ через свойство WindowProc
, что и в предыдущем примере, но т.к. теперь перехватываются сообщения родителя, а не владельца, появляются некоторые нюансы.
Установка компонента TCoordLabel
полностью аналогична установке компонента TLine
из предыдущего раздела. На прилагаемом компакт-диске находится также проект LineCoordSample для того, чтобы работу компонента можно было увидеть без установки в палитру компонентов. На форме проекта LineCoordSample находится панель, кнопка Переместитьи компонент TLineCoordSample
, который по нажатию кнопки меняет родителя с формы на панель и обратно.
Код компонента TCoordLabel
приведен в листинге 1.28.
TCoordLabel
type
TCoordLabel = class(TLabel)
private
// Здесь хранится адрес обработчика
// сообщений, бывший до перехвата.
FOldProc: TWndMethod;
protected
procedure SetParent(AParent: TWinControl); override;
// Этот метод будет новым обработчиком
// сообщений владельца
procedure HookParentMessage(var Msg: TMessage);
end;
...
procedure TCoordLabel.SetParent(AParent: TWinControl);
begin
if Assigned(Parent) and Assigned(FOldProc) then Parent.WindowProc := FOldProc;
inherited;
if Assigned(Parent) then
begin
FOldProc := Parent.WindowProc;
Parent.WindowProc := HookParentMessage;
end;
end;
procedure TCoordLabel.HookParentMessage(var Msg: TMessage);
begin
if Msg.Msg = WM_LBUTTONDOWN then
Caption := '(' + IntToStr(Msg.LParamLo) + ', ' + IntToStr(Msg.LParamHi) + ')';
FOldProc(Msg);
end;
Класс TLabel
, предок TCoordLabel
, является визуальным компонентом и сам может получать и обрабатывать сообщения, поэтому метод Dispatch
у него уже "занят". Соответственно, мы не можем диспетчеризовать с его помощью перехваченные сообщения и должны обрабатывать их внутри метода HookParentMessage
.
Сам перехват осуществляется не в конструкторе, т.к. на момент вызова конструктора родитель компонента еще неизвестен. Он устанавливается позже, через свойство Parent
, которое приводит к вызову виртуального метода SetParent
. Мы перекрываем этот метод и выполняем в нем как восстановление обработчика старого родителя, так и перехват сообщений нового. Это позволяет компоненту менять родителя во время работы программы. Писать отдельно деструктор для восстановления оригинального обработчика родителя в данном случае нужды нет, поскольку деструктор, унаследованный от TControl
, содержит вызов метода SetParent
с параметром nil
. Так как мы уже перекрыли SetParent
, это приведет к восстановлению оригинального обработчика, т.е. к тому, что нам нужно.
Если на форму, содержащую TCoordLabel
, поместить другие компоненты можно заметить, что TCoordLabel
отлавливает нажатия мыши, сделанные на неоконных компонентах, но игнорирует те, которые сделаны на оконных. Это происходит потому, что неоконные компоненты получают сообщения через оконную процедуру родителя (которая перехвачена), а оконные имеют свою оконную процедуру, никак не связанную с оконной процедурой родителя. И, разумеется, компонент TCoordLabel
имеет те же проблемы с восстановлением оригинального обработчика, что и TLine
, если на одном родителе расположены несколько компонентов. Соответственно, применять TCoordLabel
необходимо аккуратно, с учетом возможных последствий.
1.2.4. Пример PanelMsg
Программа PanelMsg показывает, как можно перехватить оконные сообщения, поступающие компоненту, лежащему на форме. В данном случае этим компонентом будет TPanel
. Для перехвата сообщений используется свойство WindowProc
панели.
Интервал:
Закладка: