ссылочку плиз

Ну ты даешь....
100 раз на форуме топтали тему.
1) Есть на народе в комплекте http://hiasm.narod.ru/Compiler.exe
2) Dilma выкладывал отдельно: http://si-tech.ru/hiasm/down/kol_delphi.rar
3) То, что выше не проверял - Dilma мне выдавал персонально через Gmail, может и сейчас там лежит.

http://si-tech.ru/hiasm/down/kol_delphi.rar я уже ставил...

Может не в то место ставил

Galkov, все именно так, но не совсем в тему как мне кажется. Что будет если я у ваших мультиков выставлю Mode=Standart А что будет с MultiElement'ом при тех же манипуляциях? Не берусь даже представить. Все это нужно делать не так, а как было предложено еще много времени назад сразу после появления динамически создаваемых схем: делать что-то типа элемента-класса со своим именем и его парный компонент - объявление объекта данного класса. Таким образом и рекурсии можно организовать и использовать его в любом месте проекта, и хранить его где угодно и что самое главное совершенно наглядно представлено объявление класса(описание схемы) и объект класса(созданная динамически схема).


в 3D MAX ссылочные объекты именно так и ведут себя. А в HiAsm это очень полезно например при использование глобальных переменных. Что будет если захочется сменить имя переменной, а проект состоит из 10тыс элементов? Или нужно мне использовать одну картинку в нескольких местах. Ссылка дает мне возможность сократить sha файл в разы(при большой картинке).


Подумаем.

Dilma,
1) Будет тоже самое, как если бы программист, создающий рекурсивную программу, забыл поставить условие, ограничивающее глубину рекурсии.
Конечно, дополнительная дуракоустойчивость не помешала бы.
Но и отсутствие таковой не может являться аргументом. Простенькое вложение, HiAsm не дает сегодня делать. Но более сложное (говоря словами нашего коллеги S_E_A, сам себе внук) - позволяет. Кончается это, правда, в конце концов смертельно.....
Т.е., все-равно технологию надо совершенствовать.

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

3) Ссылочные объекты в 3D-MAX, Word-е и т.п.., это все-таки не из языков программирования.
Все однотипные элементы у нас - это разные экземпляры одного класса. Де-факто, ссылки на мультик это разные экземпляры одного класса, который определен в мультике-оригинале.
Мне совершенно непонятно, почему наличие 3D-MAX-а оправдывает нарушения правила в HiAsm для создания нового экземпляра класса. Впрочем, не только в HiAsm - это правило для ООП, по-моему.
Конечно, в связаных копиях есть смысл. Только этот смысл более редакционного характера. И имеет отношение, скорее, к текстовой записи типа StartNumber, у которой может быть несколько сот связанных копий. И смысл при реализации совсем другой: поменял одну буквочку, а HiAsm тут же провел изменения в сотне мест программы. Это же принципиально отличается от изменения в кодах класса. Если раньше была сотня копий одного мультика (Nic, не обижайся, но мы тебя забыть не можем ) в программе - то теперь остается ОДНА.

Т.е., если есть полезность в связных копиях (с этим просто нет смысла спорить: ну есть, так и пускай), то это надо безусловно отделять от ссылки на мультик.
Это ведь не хорошо, если из-за невозможности сделать индивидуальные св-ва для экземпляров одного класса, народ будет пользоваться КОПИЯМИ (абсолютно одинаковыми, причем), а не ССЫЛКАМИ

4) Про подумаем.
Большое дело уже сделано - комментарий многострочный. Может секционировать его ???
Т.е., на какой-то строке стоит что-то типа [Parents], а дальше вышепредложенные записи в стиле INI-файла.
Остальное - как и сейчас: первая строка появляется в хинте, все, что до первого определения секции - на панели СПРАВКА. Ну и на непредсказуемое будущее есть возможность заводить другие секции...

1) Этим примером я хотел показать, что использование ссылки на самого себя возможно только в MultiElementEx и тоьлко в режиме динамики. Вот потому и имеет смысл сделать отдельный компонент для этих вещей.

Это как еще!?

3) А HiAsm "это все таки не язык программирования" Это на 50% визуальный редактор, в котором как мне кажется такие средства должны быть.

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

4) Усовершенствовать комментарии я уже давно хочу. Но немного не так. Практика показывает, что очень удобно иметь динамический список строк вида: <name>=<value>, т.е. св-во значение. Примеров использования накопилось уже много: сразу можно заменить переход к элементу через ID (multi://49086) на переход по имени, если в комментариях компонента определено поле Name(Name=MyElement тогда multi://MyElement - по моему гораздо красивее), или теже MemoryStream из патчей - как родные видятся св-ва:
FileName=Share.pas
Data=13.09.05
Description=Исправлена ф-ция....
ну и
Property_Name=Default
здесь также укладывается.

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], научите правильной командной строке для компилятора

Понимаете, Galkov, ни в одном языке программирования нельзя размещать экземпляры класса в определении самого класса. В любом случае получится бесконечная рекурсия. Для ссылки на самого себя обычно используются ключевые слова, вроде «this», т.к. они являются именно ссылками, а не экземплярами класса.

Galkov, 1),3) - так можно говорить до бесконечности. Указатели на самого себя будут и как это реализовать я уже сказал.

2) Исправлю путем полного запрета таких вложений


dcc32.exe ..elementscodeProject1.dpr

Dilma, причем тут вложения
Делаешь копию, подводишь к ней и от нее связи, запускаешь - работает
Сохраняешь файл, закрываешь, открываешь - связей нет.

Глубокоуважаемый Гость, понимаю.
У меня даже есть основания считать, что лучше, чем Вы.

Ну вот, мы поняли друг друга
Вообще, мне кажется, что ссылки - это не лучший инструмент для дублирования мультиков. Почему бы просто не сделать указатель на класс свойством мультика, тогда можно было бы обойтись обычным копированием.

Гость,
1) У меня и не было проблем с непониманием
2) Беседа будет более увлекательной, если Вы предварительно познакомитесь с уже сделанным. Ваш пост не свидетельствует о понимании, например, вышеприведенных кодов.
Потому-что это давно сделано.

Dilma,

А чего делать с ресурсами
Но проверить раннее высказанные предположения исхитрился. Т.е., они перешли из области теории в область фактов.
1) В случае однократного вложения, ДЕЙСТВИТЕЛЬНО, достаточно лишь изменить ссылку, на определенную в этом же файле переменную, и убрать из uses неиспользуемые после изменения юниты. Знаменитый пример рекурсивной сортировки после такой правки работает. 10000 значений сортирует за 10 секунд. Как говорится, попробуйте "пузырьковый" алгоритм и почувствуйте разницу.
2) В случае двухкратного вложения (случай - сам себе внук), ДЕЙСТВИТЕЛЬНО, достаточно переложить включения юнитов в implementation. Все тоже работает.

Galkov,


должны лежать в папке проекта

1-2) не править надо, а делать так:

Я думаю и многим будет казаться это более логичнее чем ссылки сами на себя. Тем более не знаю как оно у вас работало, но у меня при попытки войти в ссылку на саму себя(путь и косвенную типа "сам себе внук") заканчиваются катастрофой.

Подтверждаю, так и происходит. Нехорошо