Вообщем - это сложно.
А именно непроще одного большого компонента.
Вывод применение менеджеров в данном случае неоправдано.
Вижу пока только один выход для компонентов подобного типа
Выбор свойств в режиме диалога.Как это было представлено Dilma
в программе подобной HiAsm от мелкософта.
В противном случае данным компонентом будут пользоваться единицы.
ИМХО.

Вячеслав, раз ты высказался, то прийдется и мне - нас вместе вспоминали.
Не вижу практического применения всех наворотов, которые знать будет только автор компонента.
Я скорее в роли водителя КРАЗа
А советовать и не буду - нормальный новичок сам все поймет и решит.

В точках которого, потеряться можно.
Да ради Бога, используй штатную таблицу, я совсем не против. Уже сейчас MTStrTbl имеет для чтения базы всего три компонента, и совсем не похожа на того монстра, как StringTableMT, обладая, притом, более мощным графическим обработчиком

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

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

потому что
1) им еще никто не пользовался
2) данный набор элементов организует принципиально иной подход к построению дерева и хранению в нем информации. Т.е. сравнение с TreeView мягко говоря не уместно.


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

И я непротив твоей, пускай будет.

Я уже писал по этому поводу Dilma(в чате).
Технология менеджеров(как он сказал) разрабатывалась по принципу -
Один ко многим,то есть один менеджер для нескольких компонентов,
именно в этом универсальность(уникальность )этой технологии.
Твои же менеджеры пригодны только для таблицы.
Именно в этом-неоправданность.
Затрачены коллосальные человеко-ресурсы всего для одного компонента.

Рассматриваю.
И вижу что все сложные компоненты используют единицы.
Поэтому и хочу что бы максимально упростили - сложное и использовали все.

А менеджер кортежного дерева, тоже для чего-то может пригодится, не думаю

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


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

Не знаю не пробовал.

Отлично понимаю.Поэтому и писал


Поэтому и невижу необходимости в их применении.
То есть что 15 таблиц с разной функциональностью ,что 15 менеджеров
невижу разницы.

Сложность просто в изучении функций такого большого количества менеджеров.

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

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

Я вообще не вижу большой проблемы выбрать, например, в компоненте управления строками какой-то определенный режим, будь то Add или Insert, или Replace. Неужели, это вызывает сложность, для которой, зачем-то, необходим рисовать вот такие TabControlы. Какой в этом смысл
Неужели, у метода Add, например, есть немеренное количество свойств
------------ Дoбавленo:

Да, и то, что ты показал, одинаково подходит, что для менеджеров, что для обычных компонентов с большим количеством свойств
------------ Дoбавленo:

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

Что в твоём понятии "удаленно управлять контролом"

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

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

Согласен полностью (а так же может заменить справку) лучше один раз увидеть....

э нет. Это мы рассматривали примеры один ко многим, а не технология на этом строилась. Вопроса целесообразности структуры многих к одному мы не рассматривали. Тут об эффективности кода уже говорить не приходится(в стандартном пакете во всяком случае), но вот структурность схеме может быть увеличена на порядок. Примеры я уже давал MRA.shq, WikiCenter.sha.

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

Да можно и так назвать.

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

Да у нас вроде не спор, а обсуждение.
Спор это делать или не делать таблицу , а она уже есть.
А реально ли сделать оконный интерфейс

nesco, обновился с SVN - полный альбац.
Подскажи,
1. что сделать в примере MTStrTbl_with_EditCtrl.sha, чтобы он заработал с точки StrList.Text ?
2. как сохранить (Save) таблицу.

Tad, в новой таблице больше не будет String Delimitera, только MT-потоки. Также, в ней не будет записи, все это можно сделать на внешних компонентах и так, как тебе надо, чтобы не иметь привязки к конкретному формату записи. На данный момент в палитре есть все компоненты для записи и чтения любых форматов данных.
А примеры я не успел еще исправить.