Вверх ↑
Этот топик читают: Гость
Ответов: 4628
Рейтинг: 747
#301: 2016-11-02 14:50:32 ЛС | профиль | цитата
nesco писал(а):
поэтому первый надо заменить
Ну, собственно, ничего не будет мешать это и дальше делать. А что, эти две процедуры друг другу мешают?

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

0
Разработчик
Ответов: 26112
Рейтинг: 2124
#302: 2016-11-02 14:57:32 ЛС | профиль | цитата
Netspirit писал(а):
А что, эти две процедуры друг другу мешают?

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

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

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

0
Ответов: 4628
Рейтинг: 747
#303: 2016-11-03 12:04:10 ЛС | профиль | цитата
Вот демонстрация моей идеи 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
карма: 26

0
файлы: 1MTStrTbl mod test 2016-11-02 NS.zip [17.2KB] [636]
Разработчик
Ответов: 26112
Рейтинг: 2124
#304: 2016-11-03 14:06:51 ЛС | профиль | цитата
Netspirit писал(а):
какие проблемы возникали и решались в текущей реализации MTStrTbl?

Ну ты и вопрос задал. Я че помню, что я там правил, и что там были за баги.
Netspirit писал(а):
зачем THIMST_UseEditCtrl отключает дефолтную процедуру обработки сообщений в ThiMTStrTbl

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

0
Ответов: 4628
Рейтинг: 747
#305: 2016-11-03 14:53:36 ЛС | профиль | цитата
nesco писал(а):
Самое простое, это было перенаправить на другой обработчик
То, что нужно предотвратить дефолтную обработку в ThiMTStrTbl это понятно. У меня скорее непонятки почему было сделано именно так - полностью отрубается функция обработки в таблице, чтобы продублироваться (частично) в THIMST_UseEditCtrl.
карма: 26

0
Разработчик
Ответов: 26112
Рейтинг: 2124
#306: 2016-11-03 16:06:14 ЛС | профиль | цитата
Netspirit писал(а):
У меня скорее непонятки почему было сделано именно так - полностью отрубается функция обработки в таблице, чтобы продублироваться (частично) в THIMST_UseEditCtrl.

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

0
Ответов: 4628
Рейтинг: 747
#307: 2016-11-04 16:10:14 ЛС | профиль | цитата
А пример Example\Forms\MTStrTbl\In_IconStyles.sha только у меня не показывает иконок?
карма: 26

0
Разработчик
Ответов: 26112
Рейтинг: 2124
#308: 2016-11-04 16:31:50 ЛС | профиль | цитата
Netspirit писал(а):
А пример Example\Forms\MTStrTbl\In_IconStyles.sha только у меня не показывает иконок?

У меня показывает
In_IconStyles_001.png
карма: 22

0
Ответов: 4628
Рейтинг: 747
#309: 2016-11-04 16:55:19 ЛС | профиль | цитата
Ага, выяснил. Не показывает, если брать sqlite3.dll из папки HiAsm. А если с оф. сайта - то ОК.

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

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

0
файлы: 1MTStrTbl mod test 2016-11-04 NS.zip [78KB] [631]
Ответов: 4628
Рейтинг: 747
#310: 2016-11-07 12:20:16 ЛС | профиль | цитата
Вот такая чепуха обнаружилась в hiToolBar.pas, строка 68:
   if _prop_Ctl3D = 1 then
     Include(Fl,tbo3DBorder);
_prop_Ctl3D := 1;
Поэтому Ctl3D для Toolbar не работает.

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

0
Разработчик
Ответов: 26112
Рейтинг: 2124
#311: 2016-11-07 13:13:18 ЛС | профиль | цитата
Netspirit писал(а):
Поэтому Ctrl3D для Toolbar не работает

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

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

0
Ответов: 4628
Рейтинг: 747
#312: 2016-11-07 13:21:08 ЛС | профиль | цитата
Да тут смысл не в том, нужен/не нужен. Код - бред. Дословно: "если Ctl3D=False, сделать tbo3DBorder у тулбара. Потом, независимо ни от чего, установть Ctl3D=False".
Что мешает, если будет:
if _prop_Ctl3D = 0 then Include(Fl,tbo3DBorder);
И всё.

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

0
Разработчик
Ответов: 26112
Рейтинг: 2124
#313: 2016-11-07 14:32:00 ЛС | профиль | цитата
Netspirit писал(а):
И всё

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

0
Ответов: 4628
Рейтинг: 747
#314: 2016-11-07 14:43:27 ЛС | профиль | цитата
Так я и говорю, что код бредовый.
nesco писал(а):
откуда у тебя взялось if _prop_Ctl3D = 0
Хе, а это к любителям писать свойства типа 4 так, чтобы True было 0, а False = 1
карма: 26

0
Разработчик
Ответов: 26112
Рейтинг: 2124
#315: 2016-11-07 15:02:41 ЛС | профиль | цитата
Netspirit писал(а):
Так я и говорю, что код бредовый.

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

0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)