Да я об этом тоже думал, но остановился на решении отдать назначение сообщений самой системе, пусть она сама решает, какой код отдать сейчас конкретному сообщению. И че все прикопались к этому Case?

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

В результате, я вообще переписал ему обработчик.

--- Добавлено в 2022-01-12 15:08:43


Я столкнулся с понятием "как надо" в результате танцев с бубнами вокруг OnPaint, его надо строго инициализировать как в основном модуле и только один раз при подключении точек, если точка подключена, больше инициализировать контекст отрисовки ни в коем случае нельзя. Вот я туда и ввел переменную уже проведенной инициализации -- а проверка назначения OnPaint через Assigned, выдавала, что точка занята, а на самом деле инициализацию контекста никто не проводил.

--- Добавлено в 2022-01-12 15:18:48


В менеджерах нижнего уровня можно перехватить класс самого клиента и управлять его параметрами напрямую, кстати, это у меня и реализовано. Можно ли такое замутить для менеджеров верхнего уровня, тут надо подумать.