Ну мое дело предложить...

А, забавно "ссылку-кнопку" из примера S_E_A в редакторе можно отредактировать 1 раз.
S_E_A вот
[code:1]Add(Button,15256120,147,84) {
Left=10
Top=20
Font=[MS Sans Serif,8,0,0,1]
link(onClick,951378:doEvent1,[])
}
Add(Hub,951378,189,84)
{
link(onEvent1,5429116:doData,[(236,90)(229,90)])
link(onEvent2,14751569:doData,[(229,97)(229,132)])
}
Add(DoData,5429116,238,84)
{
Data=String(test)
@IsLib=True
link(onEventData,6653584:doText,[(289,90)(275,90)])
}
Add(DoData,5429116,238,126)
Add(Edit,6653584,280,84)
{
Left=85
Top=20
Font=[MS Sans Serif,8,0,0,1]
}
Add(Edit,1569583,280,126)
{
Left=85
Top=45
Font=[MS Sans Serif,8,0,0,1]
}
[/code:1]
(в комнаты кинуть нельзя, поэтому здесь выкладываю)

Dilma, копия-мультика не работает во вложении в этот мультик.
Т.е. опять не получилось.

Galkov, а как ты это представляешь? этож в мультик будет копироватся мульти и так без конца???

На коментарий ссылка не действует

P.S. теперя видны свойства-точки(у которых можно сделать точки они цвет шрифта как у линии между свойствами а без точек обычный черный)

Помоему такого не может быть в принципе

Эт что-то из разряда я сам себе папа

Galkov, действительно ссылка на контейнере в нем самом это что такое?

Dilma может сделать чтобы нельзя было вставлять в схему ссылки на визуальные компоненты(как в фоновом приложении)

Dilma, это то, о необходимости чего так долго твердили большевики.
Это и есть РЕКУРСИЯ
А все остальное - "кольцевание"
Более подробно: в примере внутренние два мультика надо заменить ссылками на основной. После этого пример начнет сортировать в десятки раз быстрее "пузырьковых" методов. Это не я придумал - это теория.

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

P.S. Но готов согласиться, что ссылка сама по себе ничего не знает о динамичности мультика. Поэтому, видимо, нужен контроль за конечностью рекурсии на этапе генерации кода (типа дополнительная головная боль против глупостей пользователя). А на этапе исполнения - это, естественно, забота программиста. Как и за конечностью циклов, и за многим другим

S_E_A, так и сделаем скорей всего.

Galkov, технически ссылка на компонент это тоже самое что и просто комнпонент, но с одинаковыми св-вами. Ссылка на контейнер это компонент с таким же классом, как и и то, на что он ссылается. Таким образом сделать вставка ссылки контейнер в него же не возможна физически ни в среде не в программе. Поэтому тут нужно делать отдельные механизмы.

Dilma,
И с чего это оно вдруг стало невозможным
Вот в такой схеме:
[code:1]Add(MultiElementEx,11297932,196,112) {
Mode=1
@Hint='Sorting'
}
BEGIN_SDK
Pos(0,0)
Add(EditMultiEx,16571958,3,3)
{
WorkCount='##add','##delete'
DataCount='Array'
Width=519
Height=279
link(##add,8086485:doCompare,[(8,9)(8,69)])
}
Add(If_else,8086485,14,63)
{
Type=2
Op2=Integer(1)
@Group=79009100
link(onTrue,1910364:doEvent1,[])
}
Add(MultiElementEx,4063982,119,63)
{
}
BEGIN_SDK
Pos(0,0)
Add(EditMultiEx,14552770,3,3)
{
WorkCount='##add','##delete'
DataCount='Array'
}
END_SDK
Add(Hub,1910364,63,63)
{
link(onEvent1,4063982:##add,[])
link(onEvent2,4063982:##delete,[])
}
END_SDK
Add(Button,16138926,98,112)
{
Left=115
Top=10
Height=25
Font=[MS Sans Serif,8,0,0,1]
Caption="Sort"
link(onClick,8954268:doEvent1,[])
}
Add(Hub,8954268,147,112)
{
link(onEvent1,11297932:##add,[])
link(onEvent2,11297932:##delete,[])
}[/code:1]
Получается такой код для схемы внутри мультика:
[code:1]unit hiMultiElementEx_4B4D8F8; interface
uses kol, Share, Messages, hiEditMultiEx, hiIf_else, hiMultiElementEx, hiHub, hiMultiElementEx_4B50738;
type
TClassMultiElementEx_4B4D8F8 = class
private
EditMultiEx_4B56C04:THIEditMultiEx;
If_else_4B59C7C:THIIf_else;
MultiElementEx_4B50738:THIMultiElementEx;
Hub_4B521E4:THIHub;
public
Child:THIEditMultiEx;
constructor Create;
destructor Destroy; override;
end;
TMainClass = object
function Create(Control:PControl):THiEditMultiEx;
end;
var _Create_hiMultiElementEx_4B4D8F8:TMainClass;
implementation
function TMainClass.Create;
begin
Result := TClassMultiElementEx_4B4D8F8.Create.Child;
end;
constructor TClassMultiElementEx_4B4D8F8.Create;
begin
inherited Create;
EditMultiEx_4B56C04 := THIEditMultiEx.Create;
If_else_4B59C7C := THIIf_else.Create;
MultiElementEx_4B50738 := THIMultiElementEx.Create;
Hub_4B521E4 := THIHub.Create;
//~~~~~~~~~~~~~INIT~~~~~~~~~~~~~~
with Hub_4B521E4 do
begin
_prop_InCount := 1;
_prop_OutCount := 2;
end;
Hub_4B521E4.onEvent[0] := _DoEvent(MultiElementEx_4B50738.doWork,0);
Hub_4B521E4.onEvent[1] := _DoEvent(MultiElementEx_4B50738.doWork,1);
with MultiElementEx_4B50738 do
begin
_prop_Mode := 0;
end;
with MultiElementEx_4B50738 do
begin
MultiElementEx_4B50738.OnCreate:=_Create_hiMultiElementEx_4B50738.Create; // !!!!!
SetEvents( 0 );
SetDatas( 1 );
SetWorks( '##add'#13#10'##delete'#13#10 );
SetVars( '' );
end;
with If_else_4B59C7C do
begin
_prop_Type := 2;
_prop_Op2 := _DoData(1);
end;
If_else_4B59C7C._event_onTrue := _DoEvent(Hub_4B521E4.doEvent,0);
with EditMultiEx_4B56C04 do
begin
_prop_WorkCount := PChar(LoadResData('Str3'));
_prop_EventCount := '';
_prop_VarCount := '';
_prop_DataCount := PChar(LoadResData('Str4'));
_prop_Width := 519;
_prop_Height := 279;
end;
EditMultiEx_4B56C04.Works[0] := _DoEvent(If_else_4B59C7C._work_doCompare,0);
Child := EditMultiEx_4B56C04;
EditMultiEx_4B56C04.MainClass := Self;
end;
destructor TClassMultiElementEx_4B4D8F8.Destroy;
begin
EditMultiEx_4B56C04.Destroy;
If_else_4B59C7C.Destroy;
MultiElementEx_4B50738.Destroy;
Hub_4B521E4.Destroy;
end;
end.[/code:1]
Кто мешает в строке помеченной комментариями '// !!!!!' заменить:
[code:1]MultiElementEx_4B50738.OnCreate:=Create_hiMultiElementEx_4B50738.Create;[/code:1] на:
[code:1]MultiElementEx_4B50738.OnCreate:=Create_hiMultiElementEx_4B4D8F8.Create;[/code:1] и убрать воспоминание о 4B50738-классе вообще (здесь это только в третьей строке - подключенный unit). :?: :?: :?:
Мне представляется это именно настолько простым :!: И я бы это проверил ручками (на ранее указанном рабочем примере, естественно), если бы знал, как попросить [b]HiAsm[/b] сотрудничать со мной в этом вопросе :lol:

[quote="Dilma"]...технически ссылка на компонент это тоже самое что и просто комнпонент, но с одинаковыми св-вами[/quote]
Этой фразы я вообще непонимаю. Смысл ссылки (мне думается) - убрать разницу между мультиком и встроенным элементом. А почему свойства-то должны быть одинаковыми :?:
Одинаковыми должны быть классы, ИМХО. Вот именно тогда бы программы коллеги [b]Nic[/b]-а перестали быть метровыми.
А у нас и свойства дублируются :( Честное слово - это неправильно :!:
Кстати, о свойствах мультиков. Вот в ранее злоупомянутом [url=http://si-tech.ru/hiasm/forum/viewtopic.php?p=10561#10561]примере[/url] я поставил коментарий к элементу Memory безо всякой задней мысли. Получилось некрасиво....
Думаю, что логичней было бы в коментариях писать: Property_Name=Default. И что бы такое работало на любом элементе, не только Memory. Правая часть равенства - свойство элемента, переносимое в св-во мультика с другим именем, которое в левой части. И чтобы можно было сделать несколько таких записей. Вот тогда бы была икебана :lol:

В связи с этим, мне не очень понятен смысл ссылки НЕ на мультики. А не только на визуальные элементы. НЕ мультики и так ссылочные :D

P.S. а, действительно, [b]Dilma[/b], дайте командную строку для dcc32, компилирующую полученные [b]HiAsm[/b]-ом коды (и, возможно, подправленные мною). Папка компилятора, видимо, должна быть текущей......

А DataToFile так и неисправили...

AVC, А чего там надо исправлять

Dilma, прошу прощения за неточность (не все сразу прсмотрел)
Наш коллега Nic уже СЕГОДНЯ имеет возможность делать программы не метровыми, используя технологию ссылочных мультиков.
Все-таки, по содержанию - это разные экземпляры одного (:! класса.
Тем более, непонятно, с какой такой радости у них ОБЯЗАНЫ быть одинаковые св-ва.

незнаю, просто некомпилируется с ним пишит :
что то на форуме вроде говорилось по этому поводу.

Обнови KOL