Это св-во определенное в ECreator как data_element - в качестве списка значений задаются классы элементов, которые могут быть присвоены данному св-ву. В среде автоматически строится список имен доступных на схеме элементов, и выводится в качестве выпадающего листа в редакторе св-тв. В кодогенераторах ссылку на элемент, присвоенный данному св-ву data_element можно получить по propGetLinkedElement(). Единственная особенность использования - у линкуемых элементов обязано присутсвовать св-во типа data_str с именем Name. Иначе среда выдаст ошибку.

PS: для занимающихся проблемами наследования предлагаю попутно еще подумать на тему того, как интерфейсно наследовать элементы классов DPElement и DPLElement.

nesco,Если работаешь в англ. интерфейсе, то лучше не запускать.

Для программиста всё остаётся как и было он видит два одинаковых
мультика(только знает что данный тип мультика компилируется один
раз).Собственно он для этого его и ставил.
И кодогенератор это тоже знает.

Когда-то, когда я был "такой же User, как и мы все" и только начинал разбираться со всеми этими мультиками и ссылками на мультики, помнится я выдвигал идею о том, что коллекция однотипных мультиков должна быть общей, и можно было бы получить handle от одного мультика, и воспользоваться им в ##hselect другого, который является ссылкой на мультик. Мы тогда на пару с AlexKir пытались продвинуть ООП в HiAsm, но из этого так ничего и не вышло.

Можно глупый вопрос -- а почему

По-моему такие вещи лучше делать в соответсвие с канонами классического ООП, когда есть описание класса и есть экземпляр класса. Это два разных элемента с разной функциональностью и назначением. А не мультик и ссылка на него...

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

Dilma первым делом тогда сообщил, что просто поинтеры, это - читы во всех высокоорганизованных языках программирования, и что боцман (к примеру) за такое бил сразу же канделябрами по голове. В чем я с ним был согласен тогда, и согласен сейчас.

НЕ читами является примерно такое

#pas
function(obj:TMulti)
begin
  ....
  obj.doMethod(да мало ли чего тут);
  ....
end;

Внимание, это не просто левый поинтер, а указатель на конкретный класс, и среда отслеживает, чтобы он таковым являлся. Что значит таковым - при вызове мы имеем право туда подставить и другой класс, но он обязан быть наследником исходного.
Т.е., чтобы это делать необходимо навести порядок с отношениями наследования.
ВСЕНЕПРЕМЕННО
Ну я так и сейчас говорю

Galkov писал(а):

Просто надо один раз договориться о самосогласованном решении, вот и все...

Столь подробно я не стал тогда этого объяснять AlexKir, потому-что не очень рассчитывал на успех (если уж на чистоту), а тебе не стал, потому-что ты это лучше меня знаешь

А теперь давай вспоминай, кажется AlexKir сообщал, что попробовал снять "защиту" с метода ##hselect (или его научил кто - точно не припомню уже...) и радостно сообщал, что все работает (типа - УРА). Одна незадача (с печалью он сообщал) - выходные события происходят на оригинале.
Ну, блин, не стал я его посвящать в искусство подмены EditMultiEx.FParent
Скажем потому, что еще сам не понимал, как правильно (+ вышесказанное)

Ну а теперь у меня с этим есть определенность, и аналоги из "классики"
Давай посмотрим, что есть такое точки в нашем элементе в этой самой "классике"
Левые и нижние - это методы.
Правые и верхние - это виртуальные ф-ии. Причем, если не назначены, значит абстрактные.
А подключение связи, это создание объекта наследника, только с переопределением этих виртуалов такими методами, которые вызывают другие методы других объектов.
В общем, как-то так...
И тут есть маленькая тонкость, приводящая к большим последствиям, как мне кажется
Эти абстрактные виртуалы могут лежать как в private, так и в public
Если мы только наследуем, то нам по барабану, мы можем переопределить любой
А если занимаемся объекто-указанием, то нам доступны только public
Может все это несколько коряво а только по смыслу должно быть верно

Ну скажем есть у нас адаптированный к нам класс TStream - он еще не знает, кто он такой (File или Memory), у него в секции private есть всякие виртуальные методы (Read, Write, Seek, и т.п.) которые будут переопределены конкретными наследниками.
А то, что он к нам адаптирован, означает, что к него есть в секции public абстрактный метод onRead, который переопределится при создании схемы...
Ну и что такое элемент DataToFile
Это оболочка над указателем на этот, адаптированный к нам класс TStream.
Ну, грубо говоря, не видим мы точек из секции private...
И получается, что событие onRead должно возникать на элементе указателе, а события "Read, Write, Seek, и т.п." - на элементе оригинале
Причем, не забудем, что назначаем-то элементу указателю конкретный объект, и вовсе не класса адаптированного TStream, а какого-то из его наследников - MemoryStream, или FileStream. А они отличаются от предка как раз тем, что злополучные точки "Read, Write, Seek, и т.п." у них как раз уже подключены.
И получается, что то, что эти события срабатывают в оригинале - совершенно правильно, так все в "классике" и происходит...

---

Ну ладно, это все слишком умно и непонятно. А может, и не совсем строго
И фиг с ним... Но у нас в HiAsm все эти сложности могут иметь прямую аналогию, которая нам гораздо понятнее, и достигает того же результата

Давайте посмотрим...
Скажем, мы СОЗДАЕМ элемент, используя фичу data_element, опубликованную Dilma
Фактически мы в этом св-ве (пусть, скажем, называется class) установим TMulti, из вышестоящей демки...
Когда устанавливаем, то:

Dilma писал(а):

список имен доступных на схеме элементов, выводится в качестве выпадающего листа в редакторе св-тв

Вот теперь, исходя из всего вышесказанного, такое предложение:
После выбора конкретного элемента (класса TMulti) должен появиться список точек этого элемента с чеками, и пользователю предлагается оптичить необходимые точки (грубо говоря, ну зачем мне все 150 точек от элемента коллеги nesco)
И главный результат: события на тех точках, которые появились на элементе - в оригинал не пойдут, а будут здесь, у нас. А остальные - пойдут именно в оригинал.
Вроде по-понятней и наглядней, чем всякие public/private, а результат тот же самый

Ну и у этого элемента должна точка ##obj, может быть (а может быть и нет...) и одноименное св-во того же типа, но только при установке которого лист следует делать (если делать...) не из классов, а конкретных элементов....
И тут уже - никаких оптичиваний...
Хорошо бы чтобы не просто полный лист элементов, а тех, которые являются наследниками св-ва class
Но возможно, такое навороченное св-во obj - это пижонство...
Вполне можно обойтись верхней точкой ##obj и потоком
Мне так кажется... посмотреть осталось

примеров не хватает: что есть, почему этого не достаточно и как было бы, будь оно реализовано... Из примера в несколько постов выше проблема не совсем четко прослеживается.


если речь идет о концепции, а не о конкретном пакете, то указанные точки могут трактоваться как:
левые и правые - последовательность выполнения команд
верхние и нижние - приемники и источники данных соответственно

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

Теперь попробуем представить себе пакет для HiAsm, который называется MyINI и у которого есть проект "INI file", как несложно догадаться - генерирующий по схеме ини файл. Что такое понятие "метод", "событие", "объект" или определение "абстрактный" в рамках палитры данного пакета? Или другой вопрос: что есть элемент GetIndexData в данном пакете, наличие которого по заявлениям из предыдущих постов не должено никак зависить от концепции пакета?

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

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

Все это требует каких-то своих интерфейсных элементов (если бы мы попытались сделать у себя такое - никак это идеологии FTCG не противоречит вроде), и как-то там тоже не очень применимо понятие GetIndexData
И чего теперь, застрелиться что ли...

Но как бы хотелось поговорить о задаче создания программного продукта....
Ну и какая это задача.
С одной стороны пользователь представляет информацию в нашем графическом виде, с другой стороны получает продукт
И думается мне, что здесь очень важно (если вообще не САМОЕ ГЛАВНОЕ) чтобы пользователь абсолютно точно понимал, к чему приведет то или иное действие в схеме
Т.е., мы ему должны дать точную модель происходящего (ну не знаю как лучше сказать), чтобы он мог делать адекватные выводы
И это самая главная печка, от которой надо плясать.
Мне так кажется, иначе, как бы, не очень понятно для кого все это делается

У нас есть опыт создания такой модели. Ничего лучше (и, кстати говоря - ТОЧНЕЕ), "модели паровозиков" не получилось.
То, что это аккуратно не изложено на wiki, нет видео к ней, нет исполнения этой модели в "благородных терминах" - это наша беда.
Это надо просто делать, скажем тем, кто это умеет, или как-то вместе
И, видимо, с наличия такой модели следует начинать концепцию
Пока, что думалось, что "создание программного продукта" должно этому удовлетворять.
И элемент GetIndexData совершенно не противоречит этой модели

Собственно, ничему не противоречило бы утверждение, что пакет QT выполнен в некой другой модели, кардинально отличной от "модели паровозиков"
Да, как говорится, кто же против-то....
Просто пара замечаний:

А кто об этом знает (ну пусть мы с тобой - не считаемся)

Интересно услышать ее... хотя и не обязательно... но интерсен был бы сам стиль изложения Вот и все...

Ну и естественно, говорил я в постах выше о неком интерфейсе (и это еще не окончание, мы вроде еще размышляем над тем, как бы было возможно хорошо...) для знатоков именно этой модели (паровозиков)
Да, я берусь в этой модели рассказать пользователю чего будет происходить: что событие, пришедшее слева к элементу-pointer-у породит бурную жизнедеятельность (выполнение работ по штатному расписанию именно той станции) в том мультике, на который идет указание, там будут вызываться события (поскольку это может быть наследник, то не все внутри элемента), а вот если там наверху вызывается внешняя точка, которая есть на элементе-указателе (которая, кстати, на оригинале-то не должна быть подключена), то на нем же и будет дальнейшая реакция
------------ Дoбавленo:

Dilma писал(а):

примеров не хватает: что есть, почему этого не достаточно и как было бы, будь оно реализовано... Из примера в несколько постов выше проблема не совсем четко прослеживается

Дык я не против же примеры предоставлять....
Вот только вопрос (кажется) не очень понял...

Ну может так, понятней про цели будет...
Я говорю о создании технологии, которая позволит превратить "зашифрованный" пример коллеги nesco типа ElementsdelphiExampleFormsTreeView_As_DirView.sha -- в нечто читаемое
Примерно таким образом:

Погружаем элемент TreeView в контейнер-наследователь (хотя это все еще не обговорено до конца), который имеет нижнюю точку ##handle

Разбиваем схему на отдельные независимые логические фрагменты, демонстрирующие каждый по отдельности свою фишку сего продвинутого элемента.

При этом, мы НЕ начинаем пляски с бубном вокруг этого элемента, а для обращения к нему используем элемент Pointer, который уже ненавязчиво связан только одной своей верхней точкой ##obj с вышеупомянутой точкой ##handle

Есть гипотеза, что при такой схемотехнике элементы - LineBreakEx исчезнут из схемы за ненадобностью..
Ну, как бы, цель предлагаемого мной обсуждения -- и есть выработка (придумывание - попросту) таких интерфейсных решений, чтобы эта гипотеза превратилась в великую сермяжную правду.
Вообще-то - не только.... Но это уж - как минимум

Применил на свою голову NewTechnologys, посчитал, что без линков читаться будет проще, а оно вон как вышло -- "зашифровал" получается.

А я то чего Этот термин Dilma первый применил
------------ Дoбавленo:


Так кто против-то.
Наверно это должен быть какой-то специальный элемент, со всеми характеристиками мультика, но имеющий защиту от подключения всех внешних связей. И соответственно, как-то CodeGen должен опознавать его, чтобы не создавать объект. По имени элемента - наверное не серьезно, может какой индекс класса (без дополнительного API)

Примерно в таком стиле я и пытался делать, но помещал это в контейнер-helper - коды этих контейнеров мы же не строим
Первый раз nesco огорчался на такое на примере SpriteDemo из "Этюдов". Шибко огорчался
Ну там я вытянул из контейнера, фиг с ними с созданными не в тему элементами... Демка же...
И возникло у меня подозрение, что среда терпит линки только в пределах "прямой видимости" по дереву объектов, а расположение оригинала и линка на соседних ветках этого дерева - болт с гайкою...

Так собственно, в примере, здесь выложенном - у меня вообще никаких вариантов не было...
Есть TAB, в двух его соответствующих панелях - две одинаковые схемы (тоже панели, кстати, и входить из них в редактор форм - занятие не для слабонервных).... Одна (это сегодня так) оригинал, вторая линк на него - вроде бы и вариантов нет

И еще, в том примере очень модно было в свои мультики иконки с #main вешать... Чтобы их было какое-то разумное число, многие из элементов Icon являлись линком на другой, аналогичный
Наверное, это тоже смертельно...
------------ Дoбавленo:

Ну ладно, хватит пока - рука бойцов колоть устала

Скорее не виртуальные функции, а делегаты (новое модное слово)

Давай теперь я расскажу, что я думаю о текущей концепции ХиАсм.
Можно рассмотреть эту концепцию с разных точек зрения.

Итак. С точки зрения построения программы.

Есть две сущности: процедуры и функции. И то, и другое, можно либо использовать, либо реализовывать.
Комбинация всего этого даёт нам как раз четыре возможные точки:
реализация процедуры (левая)
реализация функции (нижняя)
использование процедуры (правая)
использование фукции (верхняя)

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

Теперь с точки зрения данных.

Есть две сущности: клиент и сервер. А есть два направления данных: передача и приём.
Комбинация всего этого даёт нам опять четыре возможные точки.

НО! Данные могут быть не просто числом или строкой, а (если рассматривать ещё и с точки зрения ООП) могут являться ссылкой на объект. А если точнее, то нужно говорить об использовании и реализации интерфейса. И сейчас это скрыто внутри компонента (массивы, потоки) и не вписывается в концепцию ХиАсм (нельзя при помощи компонент сделать свой интерфейс, передать его как данные, сохранить его в переменной, использовать его). Handle мультика пока нельзя в полной мере считать интерфейсом, поскольку без самого мультика это просто число.


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

А если использовать виртуальные списки этих Pointer'ов

Про пользовательские конструкторы данных я уже как раз думал. Особенно когда надо упаковать их в массив, как в примере по OpenGL из пакета QT, где пришлось использовать три отдельных массива для хранения координат x, y и z одного и того же объекта. Это мягко говоря кривое решение задачи...

Вот как бы хотелось решить туже задачу с использование "шаблона типа":

1) делаем некий элемент с именем record(он является контейнером, но без возможности добавления точек)
2) делаем кучу элементов с именами FieldInteger, FieldString, FieldReal и т.д.
3) положим нам нужен тип данных, состоящий из одного целочисленного поля и двух строковых - делаем:

тут Контейнер это наш гипотетический элемент Record, а элементы Memory внутри - это поля, указанные выше. Точка "record" это готовый шаблон структуры
4) далее создаем элемент с каким-нибудь названием TemplateArray
где точка type - это шаблон данных, array - это массив, сконструированный по шаблону
5) ну и наконец допишем наши элементики для работы с массивами так, чтобы они понимали не только простейшие данные(как сейчас), но и такие, которые пользователь сделал с использованием среды. Причем запись/чтение можно производить, например, через МТ

Вот и получаем нехитрую схемку, которая добавляет число и две строки в наш пользовательский массив:
code_9251.txt

расширяя идею дальше, можно вставлять в элемент record скажем элементы типа ToInteger, ToString и т.д., которые по событию onConvert переведут все поля структуры в требуемый тип данных и вернут результат методом doReturn, т.е. получим полноценный тип данных.

К сожалнию минус у подхода только один: как реализовать это на базе стандартного пакета большой и толстый вопрос. Скорей всего никак...

------------ Дoбавленo:


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

------------ Дoбавленo:


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

------------ Дoбавленo:


вот такой код должен при этом получиться:

А про порядок следования элементов в записи и в МТ-потоке ты почему-то умолчал.

Насчёт использования и реализации интерфейсов: в голову приходит только нечто вроде компонента "Кабель", только для всех 4 видов точек одновременно.

А как это должен учитывать CodeGen (чтобы генерировать нормальные интерфейсы) - вообще непонятно.

Кстати, LineBreakEx очень похож на простейший интерфейс с одним методом

Я бы даже сказал, он мог бы служить для определения интерфейса внутри мультика.