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

Все это требует каких-то своих интерфейсных элементов (если бы мы попытались сделать у себя такое - никак это идеологии FTCG не противоречит вроде), и как-то там тоже не очень применимо понятие GetIndexData
И чего теперь, застрелиться что ли...

Но как бы хотелось поговорить о задаче создания программного продукта....
Ну и какая это задача.
С одной стороны пользователь представляет информацию в нашем графическом виде, с другой стороны получает продукт
И думается мне, что здесь очень важно (если вообще не САМОЕ ГЛАВНОЕ) чтобы пользователь абсолютно точно понимал, к чему приведет то или иное действие в схеме
Т.е., мы ему должны дать точную модель происходящего (ну не знаю как лучше сказать), чтобы он мог делать адекватные выводы
И это самая главная печка, от которой надо плясать.
Мне так кажется, иначе, как бы, не очень понятно для кого все это делается

У нас есть опыт создания такой модели. Ничего лучше (и, кстати говоря - ТОЧНЕЕ), "модели паровозиков" не получилось.
То, что это аккуратно не изложено на wiki, нет видео к ней, нет исполнения этой модели в "благородных терминах" - это наша беда.
Это надо просто делать, скажем тем, кто это умеет, или как-то вместе
И, видимо, с наличия такой модели следует начинать концепцию
Пока, что думалось, что "создание программного продукта" должно этому удовлетворять.
И элемент GetIndexData совершенно не противоречит этой модели

Собственно, ничему не противоречило бы утверждение, что пакет QT выполнен в некой другой модели, кардинально отличной от "модели паровозиков"
Да, как говорится, кто же против-то....
Просто пара замечаний:

А кто об этом знает (ну пусть мы с тобой - не считаемся)

Интересно услышать ее... хотя и не обязательно... но интерсен был бы сам стиль изложения Вот и все...

Ну и естественно, говорил я в постах выше о неком интерфейсе (и это еще не окончание, мы вроде еще размышляем над тем, как бы было возможно хорошо...) для знатоков именно этой модели (паровозиков)
Да, я берусь в этой модели рассказать пользователю чего будет происходить: что событие, пришедшее слева к элементу-pointer-у породит бурную жизнедеятельность (выполнение работ по штатному расписанию именно той станции) в том мультике, на который идет указание, там будут вызываться события (поскольку это может быть наследник, то не все внутри элемента), а вот если там наверху вызывается внешняя точка, которая есть на элементе-указателе (которая, кстати, на оригинале-то не должна быть подключена), то на нем же и будет дальнейшая реакция
------------ Дoбавленo:

Dilma писал(а):

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

Дык я не против же примеры предоставлять....
Вот только вопрос (кажется) не очень понял...

Ну может так, понятней про цели будет...
Я говорю о создании технологии, которая позволит превратить "зашифрованный" пример коллеги nesco типа ElementsdelphiExampleFormsTreeView_As_DirView.sha -- в нечто читаемое
Примерно таким образом:

Погружаем элемент TreeView в контейнер-наследователь (хотя это все еще не обговорено до конца), который имеет нижнюю точку ##handle

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

При этом, мы НЕ начинаем пляски с бубном вокруг этого элемента, а для обращения к нему используем элемент Pointer, который уже ненавязчиво связан только одной своей верхней точкой ##obj с вышеупомянутой точкой ##handle

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