Вот демонстрация моей идеи MTStrTbl mod test 2016-11-02 NS.zip.
Нужно, чтобы Dilma (и все, кто в теме) высказал свое мнение по этому поводу, и ответил на несколько вопросов:
- какие проблемы возникали и решались в текущей реализации MTStrTbl?
- зачем в клиенты менеджера выдавать отдельную record с данными и процедурами ThiMTStrTbl, а не Self?
- как решается проблема когда менеджер уничтожается раньше, чем клиент (как клиент может узнать, что менеджер уже уничтожен)?
- зачем THIMST_UseEditCtrl отключает дефолтную процедуру обработки сообщений в ThiMTStrTbl, и можно ли в моей реализации для обработки сообщений в ThiMTStrTbl перекрыть метод _onMessage, в нём сначала вызвать inherited, и если ни один из подписчиков не вернул True - выполнить свою обработку сообщений, иначе завершить обработку. Тогда подписавшийся THIMST_UseEditCtrl просто возвращает True на сообщения, которые он не хочет, чтобы обработала ThiMTStrTbl, и не нужно будет отключать процедуру. Кроме того, в штатной реализации можно и не отключать процедуру, просто в ThiMTStrTbl добавить поле, указывающее не обрабатывать свои сообщения, а THIMST_UseEditCtrl это поле будет включать.
- почему в визуальных компонентах (наследниках ThiWin) для перехвата сообщений используется Control.AttachProc, а не override THIWin._onMessage?

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

Ну, и если изменения будут приняты, я бы перед этим привёл код в этих файлах в удобочитаемый вид.