Это не совсем так. Мне, например, неизвестны способы обработки линков ИК без персонального учета этой ситуации в CodeGen.
Плюс к этому, я не понимаю, что такое линк на элемент.


Не вижу здесь проблемы в генерации кодов.
Но вижу недостатки.
К примеру, я хочу зарегистрировать в TabControl (через TControl.TC_InsertControl) неопределенное на этапе компиляции количество контроллов, например - Memo с Align=caClient
Скажем 1000 штук
Такой пример я на KOL-овский форум выкидывал, как тест на быстродействие переключения страниц и привязки.
Так я не знаю как у нас это сделать можно.
Точнее знаю - никак.
Но, если бы Memo помещался внутрь MultiElementEx - все работало бы.
Вопрос: имеем ли мы право требовать в такой задаче от пользователя создания дополнительных промежуточных панелей - 1000 штук кстати.
Не наблюдается логики как-то...

---

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

1) Есть вопрос о совместимости элементов друг с другом, с типом проекта, и т.п.
Почему это должно мешать решению рекурсивных задач, и зачем из-за этого придумывать обходные решения таковых - не доходит до меня

2) Есть задача создания элементов средствами HiAsm. И линки - наиболее близкий прототип для реализации этого. Почему при этом внешние св-ва мультика являются также залинкованными - непонятно мне. И тоже - с самого создания линков.

3) Есть понимание полезности линковать св-ва разных элементов. Но почему это только одинаковые св-ва, и только залинкованных элементов - непонятно совершенно.

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