Dilma,

1) Отсортируем вопросы: умение ссылаться на самого себя и свобода в определении свойств - это два независимых вопроса.

2) Но сначала про элементарный глюк:
[code:1]Add(MultiElementEx,2763959,140,210) {
@IsLib=True
}
BEGIN_SDK
Pos(0,0)
Add(EditMultiEx,3997859,3,3)
{
WorkCount='1'
DataCount='2'
link(1,7530434:doMessage,[(29,9)(29,34)])
}
Add(Message,7530434,56,28)
{
link(Caption,3997859:2,[(69,16)(9,16)])
}
END_SDK
Add(Edit,13663852,147,63)
{
Left=10
Top=110
Font=[MS Sans Serif,8,0,0,1]
Text="---"
}
Add(Button,7044785,70,112)
{
Left=70
Top=110
Font=[MS Sans Serif,8,0,0,1]
Caption="Ура"
Data=String(Ура)
link(onClick,2763959:1,[])
}
Add(Button,2719057,70,154)
{
Left=70
Top=140
Font=[MS Sans Serif,8,0,0,1]
Caption="Гм..."
Data=String(Гм....)
link(onClick,2763959:1,[])
}
Add(Edit,12501896,140,28)
{
Left=10
Top=140
Font=[MS Sans Serif,8,0,0,1]
Text="+++"
}
Add(MultiElementEx,2763959,147,112)
Add(MultiElementEx,2763959,140,154)[/code:1]
Хотитет верьте, хотите нет, а здесь были 4 связи (они прямолинейные и их легко угадать). И это даже правильно работает, пока не закроешь файл, и не откроешь его снова :D

3) Что сегодня получилось, если забыть про одинаковость свойств копий :?:
То, что копирование в таких программах, которые нам показывал коллега, теперь УЖЕ можно заменить ссылками. И она теперь не станет разбухать как на дрожах. И я спокойно смог бы запускать, например, ChessNetEx на своей 98-й с 32М на борту.
Мы сегодня действительно имеем коды ОДНОГО класса и много разных реализаций этого класса.
Так чего же теперь, убирать это свойство :?:
Логичней дополнить его возможностью рекурсивных вложений. Мне кажется странным, наличие двух элементов, отличающихся местом и локализации, и возможностью рекурсии. Никак эти два свойства друг на друга не влияют. Если умеем разобраться с рекурсией при файловой локализации, то не будет проблем и со ссылками.
Кстати о проблемах, и о сам себе внук.
Делаешь два мультика: внутри первого ссылка на второй, внутри второго - ссылка на первый. Я попробовал на своем неоднократно упомянутом примере: [b]HiAsm[/b] генерирует безупречные рекурсивные коды (смотрел :!:). Вот только одна беда:
[quote]E:\HiAsm\Elements\code\hiMultiElementEx_4B3555C.pas(5) Fatal: Circular unit reference to 'hiMultiElementEx_4B3555C'[/quote]
Причем, я понятия не имею, как с такой бедой справляться. В C++ таких проблем не бывает теоретически, все просто и понятно - инклуд внутри блока условной компиляции. Я имею ввиду конечно общую задачу рекурсий. Там без таких фокусов не обойтись.
Да, хотел отметить, что это не просто моя задачка. Существует целый класс вычислительных задач, где без рекурсий просто невозможно. Не мне Вам напоминать, про задачи синтаксического анализа (там то уж точно ни какие "кольцевания" не выручат) :D
Это я просто клоню к тому, что [b]HiAsm [/b]должен уметь решать и такие задачи. Ну ерунда ведь осталась.......

3) Про свойства. Этот вопрос не имеет большой актуальности, пока у нас не развернулась удобная система формирования свойств мультиков. А смысла в ссылках не на мультики, я пока не вижу. А они нужны, хотя бы потому, что для создания разных характеристик через верхние точки нужны еще и специальные методы в базовых элементах. Вспомним беседы, например, про doPicture, или doDefault..... А при генерации конструктора - нет проблем (кроме создания генератора конструктора :)), и именно в том объеме, про который говорил ранее - любое свойство базовых элементов мультика.
Я ни в коем случае не спорю с тем, нужны ли связанные копии. Я про то, что мухи отдельно, а котлеты отдельно.

Может провести разделительную черту по Мультик/Не_Мультик :?:
Но тогда эту разделительную линию должно быть хорошо видно.....
Например, разные цвета угловой точечки....




P.S. Кажется понял, как преодолевать надо 'Circular unit reference...'
Надо uses hiMultiElementEx_4B3197C переносить в implementation...
Но проверить не могу.....
Повторяю просьбу: [b]Dilma[/b], научите правильной командной строке для компилятора