Ну, собственно, ничего не будет мешать это и дальше делать. А что, эти две процедуры друг другу мешают?

Мне тут для дальнейшей работы нужно знать: а почему в клиенты менеджера заполняется и передаётся огромная структура TIMSTControl, а не тупо Self от ThiMTStrTbl, с которого можно получить все необходимые данные?

Да, они повторяют друг друга, но с некоторыми различиями.

Это про
Вот это я не могу сказать. Автор посчитал, что так лучше

Редактировалось 1 раз(а), последний 2016-11-02 15:02:13

Вот демонстрация моей идеи 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?

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

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

Редактировалось 3 раз(а), последний 2016-11-03 12:18:37

Ну ты и вопрос задал. Я че помню, что я там правил, и что там были за баги.

Я же написал зачем -- в THIMST_UseEditCtrl обработчик по-другому обрабатывает одноименные события. И в ThiMTStrTbl не один обработчик, а несколько. Самое простое, это было перенаправить на другой обработчик, чем лепить в один обработчик логику, и непонятно еще, как передать указатель экземпляра THIMST_UseEditCtrl в событиях, которые не поддерживают кастомных переменных, обычными методами

То, что нужно предотвратить дефолтную обработку в ThiMTStrTbl это понятно. У меня скорее непонятки почему было сделано именно так - полностью отрубается функция обработки в таблице, чтобы продублироваться (частично) в THIMST_UseEditCtrl.

КМК, это самый простой вариант. Иначе пришлось бы отлавливать наличие THIMST_UseEditCtrl, ставить логику, как-то передавать указатель на экземпляр THIMST_UseEditCtrl.

А пример Example\Forms\MTStrTbl\In_IconStyles.sha только у меня не показывает иконок?

У меня показывает

Ага, выяснил. Не показывает, если брать sqlite3.dll из папки HiAsm. А если с оф. сайта - то ОК.

Итак, к сообщению прикреплены дальнейшие изыскания по поводу MTStrTbl. Есть три папки и описание того, какие изменения проводились в каждой папке относительно предыдущих. Сделано, чтобы можно было сравнивать изменения между ними.
Для тестирования содержимое папок по очереди закинуть с заменой в папку code.

Редактировалось 1 раз(а), последний 2016-11-04 16:56:22

Вот такая чепуха обнаружилась в hiToolBar.pas, строка 68:
Поэтому Ctl3D для Toolbar не работает.

Редактировалось 18 раз(а), последний 2016-11-07 13:23:06

Действительно, оригинально. А он точно нужен?

Редактировалось 1 раз(а), последний 2016-11-07 13:16:31

Да тут смысл не в том, нужен/не нужен. Код - бред. Дословно: "если Ctl3D=False, сделать tbo3DBorder у тулбара. Потом, независимо ни от чего, установть Ctl3D=False".
Что мешает, если будет: И всё.

Редактировалось 3 раз(а), последний 2016-11-07 13:22:40

Не понял. Условие изначально стояло if _prop_Ctl3D = 1 then, откуда у тебя взялось if _prop_Ctl3D = 0? Я вообще выкинул весь этот код, и ни фига не заметил разницу, кроме появления бордюра при Ctl3D=True. Те я вообще не понял, для чего этот tbo3DBorder, и что он делает, если бордюр появляется сам при Ctl3D=True?

Так я и говорю, что код бредовый.
Хе, а это к любителям писать свойства типа 4 так, чтобы True было 0, а False = 1

Так вообще его выкинуть надо, если он ни на что не влияет.