SendMessage наследнику TObject

← →
DFT (2008-10-11 16:22) [0]

Здравствуйте!

У меня следующий вопрос.
Как послать пользовательское сообщение экземпляру класса TObject, ведь у него нет дескриптора?

В тоже время сообщение я посылаю не именно TObject, а его наследнику, у которого есть метод обработки необходимого сообщения.
Но как мне тогда зарезервировать для моего переопределенного наследника TObject, дескриптор?

← →
oxffff © (2008-10-11 16:28) [1]

procedure TObject.Dispatch(var Message);

← →
oxffff © (2008-10-11 16:35) [2]

> oxffff © (11.10.08 16:28) [1]

Ну это если наследник использует динамические методы в качестве обработчика конкретных сообщений, если нет (он может сделать это централизовано в оконной процедуре через case, либо .. др. без опоры на динамические методы), тогда отладчик в руки.
Но в твоем случае я практически уверен хватит [1].

← →
DFT (2008-10-11 16:35) [3]

> procedure TObject.Dispatch(var Message);

А как быть с посылкой сообщения, ведь все функции требуют в качестве параметра дескриптор:

SendMessage(

HWND hWnd, // handle of destination window
UINT Msg, // message to send
WPARAM wParam, // first message parameter
LPARAM lParam // second message parameter
);

PostMessage(

HWND hWnd, // handle of destination window
UINT Msg, // message to post
WPARAM wParam, // first message parameter
LPARAM lParam // second message parameter
);

← →
DFT (2008-10-11 16:41) [4]

Извиняюсь, понял.
Надо вызывать именно метод Dispatch(var Message), для отправки
(сначала подумал что этот метод нужно перекрыть)

← →
DFT (2008-10-11 16:41) [5]

Да. И перекрыть его тоже нужно

← →
oxffff © (2008-10-11 16:44) [6]

const WM_USER10=WM_USER+10;

type
TmyMessage=record
Msg: Word;
Txt:string;
end;

TMServer=class
public
procedure Message10(var Message: TmyMessage); message WM_USER10;
end;

procedure Useit;
var a:TmyMessage;
b:TObject;
begin
a.Msg:=WM_USER10;
a.Txt:="This text is the inner parameter";
b:=TMServer.Create;
try
b.Dispatch(a);
finally
b.Free;
end;
end;

procedure TMServer.Message10(var Message: TmyMessage);
begin
showmessage(Message.Txt);
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
Useit;
end;

← →
oxffff © (2008-10-11 16:48) [7]

> DFT (11.10.08 16:41) [5]
> Да. И перекрыть его тоже нужно

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

← →
DFT (2008-10-11 16:50) [8]

Спасибо, теперь все понятно

← →
Palladin © (2008-10-11 16:52) [9]

и в чем преимущество такого подхода перед простым вызовом метода?

← →
oxffff © (2008-10-11 16:58) [10]

> Palladin © (11.10.08 16:52) [9]

Если это вопрос мне. :)

То я бы ответил так, нет необходимости соблюдать

обеспечение полиморфизма без обязанности реализации базового двоичного контракта(читай!!! абстракный базовый класс aka интерфейс).
Это гибче. Но за гибкость придется заплатить скоростью вызова. ;)

← →
Palladin © (2008-10-11 17:02) [11]

> Но за гибкость придется заплатить скоростью вызова. ;)

и безконтрольностью...

← →
oxffff © (2008-10-11 17:05) [12]

> Palladin © (11.10.08 17:02) [11]

Это как?

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

> Palladin © (11.10.08 17:08) [13]

Ну исполнение/не исполнение решается просто

TmyMessage=record
Msg: Word;
ResultStatus:TNeededType;
Txt:string;
end;

> слежение за определением непересекающихся значений констант
> WM для разных классов.

А как тогда Windows вообще работает?
:)

> больше проблем на мягкое место нежели полезностей для желудка.
> ..

Вот это правда.
Здесь нужно четко понимать, что необходимо сейчас, что будет нужно завтра, и что было бы хорошо сделать послезавтра.
И выбрать вариант в зависимости от выразительности реализации выбранным вариантом нужной потребности.

> выразительности реализации

Я бы еще добавил
Краткости и элегантности.

> А как тогда Windows вообще работает?

У виндовса это реализовано совсем по другой причине. По причине архитектуры взаимодействия ОС и приложений, каковая есть именно событийная. Основным источником событий - является пользователь. Это логично. Самый простой выход для кучи приложений, даже просто элементов интерфейса, написанных на разных языках программирования. Но внутри самого приложения данная архитектура, на мой взгляд, абсолютно неоправданна. Всё что работает с пользователем и так работает через события. Все остальные задачи решаются более эффективно.

> > выразительности реализации Я бы еще добавилКраткости и
> элегантности.

+ сто тыщ миллионов :) для себя же пишем...

SendMessage наследнику TObject Найти похожие ветки