Dilma, по поводу идеологии, изложенной в вышестоящем примере.

1) Первый Tip:
Место расположения определения класса не является особенно принципиальным. Для меня, по крайней мере. Меня больше интересуют возможности получения результата в проге. И какие затраты для программиста это требует.
Здесь больше играет роль, наверное, совместимость с уже имеющимся. А сегодня мы имеем то, что любая схема, в любом мультике, является определением класса.

2) Про второй Tip:
Вы могли обратить внимание, что это как раз то, что я сегодня использовал а примерах. И даже думаю, что это надо внедрить в MiltiElementEx.doWork. Например так:
[code:1]procedure THIMultiElementEx.doWork; var F:THIEditMultiEx; Cnt:integer;
begin
if FChild = nil then begin
//_debug('Please set sub sheme')
F := FOnCreate(FControl);
F.Parent := Self;
FList.Add(F);
Cnt := FList.Count-1;
_hi_OnEvent(F.Works[Index],Data);
THIEditMultiEx(FList.Items[Cnt]).MainClass.Destroy;
FList.delete(Cnt);
end else _hi_OnEvent(FChild.Works[Index],Data);
end;[/code:1]И [b]Ампер[/b] не будет напуган иностранным сообщением, и, действительно, удобно.

3) Третий Tip:
Отлично. Только это уже можно делать сейчас, и это не закрывает всех потребностей рекурсивного вызова. Хотя какие-то рекурсивные задачи это решает. Не будем далеко ходить, а попробуем использовать это в примере рекурсивной сортировки. И я пока не представляю, как там обойтись этим методом. Именно из-за верхней точки....
Наверное можно, если массив на элемент подавать через входной поток посредством DoData, а не через верхнюю точку, внутри мультика фиксировать его в Memory, и вместо рекурсивных вызовов делать вызов внешнего метода "закольцованного" на вход, помещая при этом новые массивы тоже в поток, опять же посредством DoData.
Может и получится.....
Но назвать это более понятным, у меня язык не поворачивается. А по кодам - просто больше переходов из мультика в мультик.
Ну определили мы класс. Так это еще ни о чем не говорит, оказывается, пока не устроишь внешнее кольцевание. Не думаю, что такая реализация именно этой задачи будет более понятна многим, чем ранее [url=http://si-tech.ru/hiasm/forum/viewtopic.php?p=10561#10561]приведенная[/url]. А по жизни задачки и похитрей могут встретиться.
Ну а если "колечко" более понятно - так на здоровье :!: Оно прекрасно реализуется сегодня. А доработку типа OnlyOnce я просто поддерживаю.

4) Четвертый Tip
Ну тут думаю и спорить не о чем. В другой файл, теоретически, можно вынести любую схему мультика. Смысл диспута был не в разделении на шаблон/реализация (хотя мне и кажется что особого смысла городить огород - нету), а в возможности или нет при определении этого шаблона использовать реализацию его самого.
И запрет мне кажется надуманным, чисто логически. Если мы определяем шаблоны, то для того, чтобы наделить их правами других элементов. А внутри шаблона мы можем использовать все элементы, в том числе и определенные через эти шаблоны. И тут на тебе - радость :!: Не все оказывается - себя нельзя. С чего :?: Рекурсий все равно не избежать, они могут и косвенными оказаться...

[quote="Dilma"]Сделать такое рекурсирование на самого себя действительно не сложно и если вы опишите решение указанных выше проблем, то почему бы и не добавить? ( Проблемы с кодом меня не интересуют ).[/quote]
1) Ну про коды не говорим - договорились, что на сложно.

2) Так в том то и дело, что в интерфейсной части мне представляется все нормальным и понятным. И необходимости в принципиальных изменениях как-то не усматриваю.
Если просто преодолеть явно выраженные сегодня глюки. Ну это катастрофа при гулянии по рекурсивным вложениям, и корректный прием средой уже правильного SHA-файла (о правильности файла сужу только по его логической непротиворечивости).
Сегодня дело обстоит так:
[list]а) любая схема внутри мультика - это определение класса (или ЭЛЕМЕНТА в терминологии пользователя)
б) копия мультика - это создание нового класса
в) ссылка на мультик - это создание реализации класса-оригинала
г) существуют ли у мультика конкретные реализации, и их количество - зависит от установленного свойства Mode, от предыстории вызванных методов[/list:u]
Ну и не вижу в этом ничего плохого.
3) Вот не совсем понятна мне история с копированием свойств....
Но, пока нет развернутой системы формирования свойств у мультиков, это можно и не обсуждать.
А что такое ссылка не на мультик, мне не очень понятно. Здесь есть только безусловное дублирование свойств.
Фича введения связанных копий, конечно, очень полезна. Как я представляю, было бы полезно иметь, например, одну числовую констнату, которая может появиться в Default-е счетчика, в формуле, в тексте, наконец. Иконка программы могла бы гарантировано совпадать с картинкой на форме, или с иконкой дочерней формы. Это все бесконечно полезные вещи. Могли бы быть. Если бы они не привязывались к элементу. Хочу я иметь гарантированное совпадание свойств End элемента For. Но никак не могу понять, за какие провинности меня заставляют чтобы совпадало и св-во Start. Видимо ссылки на визуальные элементы не очень применимы именно по этой причине......
Ну вот и получается, что использование фичи связанных копий ограничено тем, что они выполняются сразу пучком для всего элемента. А использование ссылок на мультики будет ограничивать пользователя тем, что нельзя поставить индивидуальные св-ва (у нашего коллеги это могла бы быть шахматная фигура).

Но это все второй вопрос, как мне представляется, хотя и с непонятным пока решением...