Работаем с ApplicationEvents.OnMessage

← →
VID © (2003-12-21 19:17) [0]

Допустим моё приложение получает сообщение WM_USER+560, и получение этого сообщение, обрабатывается в указанном обработчике (if msg.message = wm_user+560 then begin ... end;).

вопрос, как сделать так что бы дальше этого обработчика событие уже не пошло, т.е. что бы во-первых в моей программе никто и ничто не отреагировало на него (handled := true ?), и во-вторых, что бы вообще никакая другая программа загруженная на этот момент в озу, не получила бы это сообщение (CancelDispatch ?) ?

← →
VID © (2003-12-21 19:21) [1]

Удалено модератором
Примечание: Флуд

← →
Nikolay M. © (2003-12-21 21:37) [2]

Второй параметр сообщения (Handled) о чем-нибудь говорит?

← →
VID © (2003-12-21 21:48) [3]

Удалено модератором
Примечание: Флуд

← →
GEN++ © (2003-12-21 22:09) [4]

>и во-вторых, что бы вообще никакая другая программа загруженная >на этот момент в озу, не получила бы это сообщение >
>(CancelDispatch ?) ?

Посылайте сообщение WM_USER+560 адресно, только Вашему окну.

← →
Nikolay M. © (2003-12-21 22:16) [5]

> {кстати, неплохо иногда читать то что пишут в скобках}

Да, проморгал, каюсь :?) А если знаешь ответ, зачем спрашиваешь?

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

Как ты себе это представляешь? Допустим, рашил я сделать два SendMessage-а программам calc.exe и winamp.exe и что мне помешает это сделать?
В принципе можно повесить хук на SendMessage и PostMessage и отследить, какому окну отсылается данное сообщение, но не думаю, что это того стОит. Сказал бы хоть, что делаешь.

Да ничего особенного я такого не делаю, просто меня сбивает с толку, а вернее я не понимаю, что значит вот эта заметка в дельфовом хелпе по сабжу:

Note: Call the CancelDispatch method from an OnMessage event handler to prevent the application from forwarding the event to any other application events objects.

Как это понять(перевести) ?

>GEN++ © (21.12.03 22:09) [4]
Я отсылаю сообщение своей проге при помощи PostMessage(Application.Handle....); т.е. прога сама себе щлёт сообщение - да просто я таким образом убиваю динамически создаваемый таймер, иначеж как его убъёшь когда он не нужен становится...

Что касается прибития таким образом TTimer - все логично, но что касаеися "распространения"
PostMessage/SendMessage по памяти, то мне представляется это так:
PostMessage регистрирует Ваше сообщение в таблице (очереди) сообшений ОС сопровождая его номером
процесса (хэндла) к которому оно адресовано.
ОС в свою очередь, в очередной квант времени предназначенный для передачи сообщений
дергает(вызывает) соответствующую стандартную процедуру обработки в приложении, которому
оно адресовано. Если Вы в своем приложении не перекрываете этоn обработчик своим,
то прием сообщения заканчивается "ничем" и никакого движения дальше вроде бы быть не должно.
Я конечно не претендую на абсолютную точность моих рассуждений.

Толь не "ОС ... в очередной квант времени предназначенный для передачи сообщений", а сама программа, когда она готова обработать сообщения из очереди, обращается к ф-ции API GetMessage(), выход из которой означает, что на верху (или внизу? ;) очереди этого приложения есть необработанное сообщение, которое и возвращается. А дальше уже приложение его как умеет обрабатывет (стандартно - вызывает API ф-цию DispatchMessage(Msg)).

Работаем с ApplicationEvents.OnMessage Найти похожие ветки