Доброго времени суток. Появилась необходимость создать менеджер, обрабатывающий сообщения типа клика мышки, нажатия кнопки клавиатуры и т.п. Нужно это для OpenGL-приложения и реализации GUI в нем. Как работают messages, шарю очень слабо, потому два вопроса :
1. Что должен иметь мой класс для перехвата сообщений, помимо методов-распаковщиков сообщений типа     
procedure WMMButtonDown(var Message: TWMMButtonDown); message WM_MBUTTONDOWN; ?
2. Можно ли осуществлять перехват сообщений несколькими "контролами", то есть моим классом(он вообще-то наследуется от TCоmponent) и, скажем, формой?

Это сообщение отредактировал(а) C4Grey - 26.8.2010, 15:19

По конкретней вопросы формулировать можно? Или надо всё вытягивать? Обязанности какие мэнэджер должен выполнять?

Добавлено через 10 минут и 32 секунды
Гуй ты будешь рисовать на OpenGL?

2cat512
Перехватывает сообщения, рассылает клиентам, определяя активные слои елементов GUI. Сообщения для елементов GUI передаются в виде выполнения метода DispatchEvent, который активирует определенное событие, при его наличии, проверяет определенные флаги...но это уже архитектура OpenGL-части, и к вопросу отношения прямого не имеет. Соответсвенно, в теле метода WMMButtonDown, для примера, будет выполнен DispatchEvent с соответсвующим аргументом, который отвечает за тип события. По идее, там может быть любой код, вплоть до банального вывода сообщения.
Соответственно, если я просто напишу класс, добавлю к нему только методы обработки событий, создам экземпляр, и т.д., при клике на форму будет обрабатыватся метод клика формы, но не метод менеджера. Надеюсь, немного прояснил ситуацию. Извиняюсь, что спрашиваю такие примитивные вещи, но сложно сформулировать правильный поисковый запрос, слишком много информации не по теме нахожу.

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

Понятно. Начнём с простого. Рассказываю, о самом принципе, потом можешь его усложнять. 
В программе, использующей Vcl, есть основной поток управления,
в котором осуществляется диспетчеризация сообщений.
Основной объект осуществ. диспетчеризацию - Application.
Application - реализует цикл выборки сообщений. Цикл находится в методе ProcessMessage(Msg) ;
Цикл упрощённо выглядит примерно так:
//Хотя там вместо GetMessage - PeekMessage, и много ещё чего.
  
Соответственно тебе надо вклиниться до DispatchMessage. После DispatchMessage, сообщение уходит конкретному контролу и продолжает обрабатываться там.
Чтобы вклиниться в цикл сообщений есть три варианта;
1.Либо написать свой цикл с нуля (Возможно бы я выбрал этот вариант, всё зависит от сложности системы)

2 Сделать потомка TAppliaction.
тогда нужно
A. Ввести новый метод ProcessMessage(Msg), обрабатывая только сообщения от мыши и клавы.
Б.Добавить метод диспетчеризаци Dispatch для OpenGL;
В. Сделать вызов Из ProcessMessage метода Dispatch.

3. Использовать Application.OnMessage.
У Объекта Application есть свойство - OnMessage, типа указатель на метод. Ты можешь использовать его, в своём Мэнеджере примерно так:

Ещё бы ситуацию немного прояснило реализация Гуя в OpenGL  Если у тебя объекты гуи реализованные от TObject то можно виндовые сообщения не транслировать в события OPENGL, а отсылать как есть. Ну это уже к другой теме относится.


Это сообщение отредактировал(а) cat512 - 26.8.2010, 23:57

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

Зашел на форум, случайно кликнул на профиль и вспомнил, что обещал отписатся :( . Извиняюсь, вылетело начисто с головы. В общем, как и говорил, выбрал 3 вариант, работает отлично, учитывая что к проекту могут подключатся моудли, использующие сообщения, приходящие форме - Handled выставляю в False и все отлично работает. Сделал установку глобального состояния кнопок мыши, координат и т.п. Экземпляры классов событий на ходу не создаются - так как события обрабатываются "в порядке очереди"  - создл класс менеджера событий, который хранит по экземпляру на каждое заранее известное событие мыши, он хранит "слушателей", которые знают, какому контролу они принадлежат. Создание событий во время работы программы, особенно при перехвате WM_MOUSEMOVE тормозило программу, потому и пришлось немного похитрить. Но в итоге все работает, пользователь свободно может добавлять любые события, сам создавать типы событий и т.п. Выбор пользовательских событий, конечно работает по принципу банального поиска в списке и сравнения строк - но тут уж ничего не поделашь :( . 
P.S. Еще раз спасибо, тема, IMHO, закрыта