И в чем же проблема тогда....
Давайте договариваться про API, и не жалко выходные потратить на соотв. dll-ку
Ну RTCG - так RTCG.... Нам татарам: что наступать - бежать, что отступать - тоже бежать...


Помню - такие варианты мы проговаривали...
Если забыть про наследование, то да - без изменений в среде вроде бы, как бы, можно бы и обойтись...
Хотя фишка с data_element мне представляется перспективной - она позволяет (теоретически) создавать нечто похожее на линки, но в разных интерпретациях. Скажем концепцию: схема (внутри мультика) - это всегда лишь определение класса, снаружи - она не значит ничего, а реальные экземпляры - элементы с таким св-ом, которые вовнуть как бы залазить и не позволяют. Типа - инкапсулировано насмерь


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

---

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


------------ Дoбавленo:


Ну и славненько
И чего мы тогда друг-другу голову морочим
В смысле: а чего БЫ

Вопрос про диалоги остается (среда накопила список классов - типа такого)