nesco, у StrList появилась doGetIndex, очень удобная, как выяснилось.. Нельзя ли нечто подобное привинтить к StringTableMT? Скажем, указываешь в MT-потоке индекс столба и искомые данные.. На выходе соответственно индекс строки.

Похожее уже есть -- doMT_FindText, и пример даже есть в новой версии HiAsm'a

да, конечно. Но если сделать поиск по столбу (желательно с регистром), он будет работать быстрее, чем doMT_FindText или также?

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

ясно, тогда у Dilma видимо нервы не стальные, а нано

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

не всегда оно наглядно на схеме, в том же TVT - обязательно нужно посмотреть в свойствах - к какому именно TreeView оно относится. Толи дело в массивах (или файл-стримах, или бассах, или ...), даже если обработка происходит в нескольких местах схемы - это видно по связям Array - про какой именно массив идёт речь. Исключение - использование LineBreakEx - когда кликаешь по Data выделение передаётся только одному Var (с ивентами та же картинка), а жаль..

Еще кто бы вразумительно сказал на какие

да не всегда. Так же как при визуализации такой связи на примере Array в крупных схемах половина линий уходит как раз на то, чтобы все Handle перевязать друг с другом. Кроме того имеется и чисто интерфейсный недостаток - одна верхняя точка всех таких элементов всегда тратится на полностью бесполезную в работе связь, не несущую по сути никакой смысловой нагрузки(смотреть что с чем связано как правило нужно не так уж часто и только во время последующих доделок).

недостаток в отсутствие визуальной связи между менеджером и клиентами устраняется достаточно просто и некоторые варианты конкретных решений уже обсуждались на форуме. Поэтому это только вопрос времени.

nesco, а как на счет поддержки MT (по типу TreeViewTrain) в том же ListBoxEx? ^_^

С выходом в свет новых бокс-менеджеров, я не буду больше поддерживать BoxEx компоненты

nesco, проверь методы doSave и doLoad у компонента StringTableMT при всех включённых опциях сохранения: у меня после сохранения в файл таблицы, загрузилось после запуска совсем не то, что было в ней первоначально.

Nic, пример в студию, где неправильно работают методы doSave и doLoad. Здесь играет роль не просто включение всех функций записи, а синхронизация с соответствующей поддержкой включения свойств в самой таблице

Очень может быть, что именно так как ты говоришь, но кто об этом знает, кроме тебя конечно?

Если делать описание к этой таблице, то оно займет добрый десяток страниц. И не факт, что все взаимодействия удастся описать сразу. Это меня и сдерживает. Боюсь, что написав хэлп к этой таблице, читать его будут единицы и также будут задавать вопросы по непонятным местам