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

а теперь будем со знаком "-" вписывать то что не работает ...

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

Уважаемые коллеги, мне представляется, что не том вы говорите.
И уж точно - не в том стиле.

У меня есть совершенно конкретное предложение: давайте поговорим на тему, которую можно назвать "спецификация языка программирования HIASM"
Естественно, давайте говорить не с чистого листа, а опираться на то, что мы сегодня имеем
Придумывать необходимые интерфейсные решения совместно.

Ну есть у меня какие-то соображения на этот предмет...
Но они не являются законченными, например из-за того, что сомневаюсь что именно так (как именно мне приперло в голову) будет понятно всем.
"Будет понятно" - именно в том смысле, что будут помогать думать над алгоритмом, а не создавать дополнительные заморочки для пользователя
Вот так я предлагаю...
Причем, наш разговор должен быть именно интерфейсным
Никакого отношения к конкретному пакету, какому-то компилятору, какой-то библиотеке
Хотелось бы, что бы результатом нашего рассуждения была фраза такого типа: "Вот такую задачу программисту на HiAsm удобней решать именно так: <описание>"

Ну а результаты нашего обсуждения (это самое <описание>) давайте изложим именно по "форме", предложенной Dilma.
Даже неделя труда по описанию этих всех "винтиков", это НИЧТО, по сравнении со временем, уже потраченным безрезультатно.

---

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

Не моя фраза, но не вызывающая ни малейших сомнений: 90% успеха работы программиста, это правильно созданные типы данных
Что такое структура данных в HiAsm
Да просто мультик, в котором мы помещаем эти данные: Memory, MemoryStream, Bitmap, да и другие мультики...
И можем нарисовать кучу необходимых методов.
Пока все в порядке.
А теперь давайте вспомним, что такие данные формируются не всегда, чтобы использовать это дело в одном экземпляре
Что мы можем использовать в нескольких экземплярах
Правильно, элемент.
И чего получается, в конкретной задаче мы формируем конкретный именно для этой задачи класс данных, и вынуждены запускать ECreator, помещать его в палитру элементов
Не слишком ли много суеты для простейшего действия
И что, для следующего проекта перестраивать палитру элементов в HiAsm

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

Получается что у нас должно быть два совершенно разных типа некого "линка": новый экземпляр того же класса, что и в оригинале, и указатель на некий конкретный экземпляр
А мы что имеем...
Имеющийся у нас линк обладает теми же самыми св-вами что и оригинал, а это характерно как раз для указателя
У нас графически отличаются линки от оригинала, что было бы совершенно логично именно для указателей - если это разные объекты одного класса, то они по жизни совершенно равноправны. Разве можно сказать про несколько элеменов MemoryStream, что один из них оригинал, а остальные - линки на него...
Но линк у нас это совсем не указатель, это именно новый экземпляр класса объекта-оригинала. По крайней мере в пакете Дельфи
Так сделано давно...
Так получилось....
И "так" будет и дальше получаться, если мы не определимся до построения, чего строить-то хотим: самолет или подводную лодку

Вот я и обращаюсь, уважаемые коллеги, давайте таки определимся, чего мы хотим

Ну и, получивши звание теоретика, я приведу пример из конкретной практической схемы...
Могу и выложить (хоть и большая), проблем нет. Но для затравки - на словах
У меня есть некий программатор.
У него есть разные табы: FUSE, FLASH, EEPROM, LOCK, Test
На вкладках FLASH и EEPROM тот кусок который выполняет чтение из камня - ну совершенно одинаковые, даже координаты визуальных контроллов совпадают
За исключением одного (в смысле - двух разных) мультика, у которого одна левая точка - doRead, и три правых - onSend, onResult, onStop
Точки-то одинаковые, а работают по разному - даже разным количеством выходных событий плюются, в ответ на входное

Как было бы делать совершенно правильно: вместо этого отличающего мультика установить некий указатель на объект. Ну предположим, что сам объект в этом гипотетическом элементе-указателе мы принимаем через некую системную точку ##obj
Тогда получилась бы одна схема, которая реализована в двух экземплярах, и эти оба экземпляра подключены к точке ##handle статического
мультика.
Каждый к своему, естественно.

Вот есть такая совершенно практическая потребность...
Повторю вопрос, коллеги: "Как должен поступать программист HiAsm, встретивши такое "
высказывайтесь

Galkov,
Немножко не понял.
Мультики одинаковые или всё же различаются?
Входные данные одинаковые или нет?

Вячеслав, это, похоже, совсем другая концепция

Ну хорошо, вот схема.
Ничего не правил - рабочий вариант. Только два красных ромбика добавил
Кусочки схемы начинающиеся с панели <Диалог READ> в табах FLASH и EEPROM - совершенно одинаковы
Кроме мультиков под ромбиками

Дык чего хочу: чтобы схем было не ДВЕ, а одна

Ну не знаю другая или нет но, я тоже так хочу,а может в QT это реализуемо.

Ну вот всё сразу стало понятно
Чё то отлично вижу как это сделать в делфи ,а как
в HiAsm не врубаюсь.
Это выходит что у нас нет такой элементарщины.

Видишь ли, Вячеслав, таки не спроста я хотел поговорить именно интерфейсно
Без ссылок на конкретный пакет.
Мне кажется такая логика была бы более правильной: если мы решили для себя <в таких случаях Хиасмист должен поступать так: .....>, и если какой-то пакет не поддерживает такого решения - то это есть проблема именно этого пакета, не все на нем можно сделать оказывается, и это явление временное.
Но, пока я чаще слышу другое несколько... Не удивлюсь, если окажется что GetIndexData - это есть некое недоразумение, и его следует ликвидировать из всех пакетов... Вот, почти это и сказано:

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

Скажем, в пакете Дельфи я могу придумать "читы" выполняющие обе задачи (рекурсию, и указатели на объект)

мультику добавлю св-во Name

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

В CodeGen добавлю персональную обработку такой ситуации

Ответственность за то, что компиляция пройдет успешно (что имена методов будут не левые, к примеру) уже будет лежать на пользователе, т.е.. определенная продвинутость уже потребуется...
Да легко И все будет работать (у теоретиков такое тоже случается). А вот правильно ли так поступать ...................

---

А про схему еще скажу...
Там на "основной мультик" (с жирным восклицательным знаком) "со всей страны" события поступают.
Ну в данной схеме это была одна связь. Да и то, потому-что обратные данные принимаю через глобальную переменную Answer
Ну простой протокол для программатора (32-х битный обмен, последний байт обмена - результат), не виноват я
Но такой же "менеджер" (с жирным восклицательным знаком) для обмена с координатным столом - дык там под сотню точек подваливает, долго же трудился

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

это уже сделано. См. ECreator в последних обновлениях.

На счет обсуждения поведения элементов в HiAsm чисто на интерфейсном уровне: не готов участвовать в подобной беседе, пока не уверуюсь в том, что возможно оптимально строить схемы по абсолютно идентичной логике для любого компилятора, языка, ОС, среды, кодогенератора и проч. Либо мы обрезаем функционал пакета, либо наоборот - перегружаем его кодом, обеспечивающим совместимость. Если принять эти допущения, то да - говорить в таком духе действительно имеет смысл.

А можно поинтересоваться -- в каком пункте это реализовано и как

Фраза, вызывающая удивление
Настолько, что возникает ощущение, будто говорим совершенно о разных вещах....

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

И самое главное, мне и постановочная часть совсем не кажется законченной.
Собственно, я ждал каверзных вопросов от коллеги tsdima, который такие вещи сечет на раз
Все это (указатель на объект) похоже на ##hselect для чужого экземпляра.

Тут надо дополнительно решить два вопроса:

кого можно hselect, а кого нельзя. А для этого надо разобраться аккуратненько с тем, что есть наследование, как это выглядит в интерфейсе, и какое CGT-Api для этого требуется.

где будут происходить ответные события: на точках оригинала, или на точках "указателя". Мне представляется, что обе возможности крайне необходимы, разрешать это надо на уровне интерфейса для каждой точки, и готов аргументировать конкретными примерами... Но конечно это достойно глубокого обсуждения с коллегами - у них тоже примеры могут найтись.
Ну как бы я не виноват, что этот вопрос более сложный, чем кажется на первый взгляд.
Что здесь смешивается все сразу: наследование, объекто-указание, множественность экземпляров одного класса...
Я просто правду рассказываю, что это НАДО...

Просто надо один раз договориться о самосогласованном решении, вот и все...
К чему и призываю коллег - давайте подумаем

Ну интерфейсно типа для всех одинаково, я вижу как:
В компонентах иметь такое свойство.
И специализированный мультик для данного вида схем.

Ну ты типа - сказанул
По всякому к твоему "вижу" - надо видео какое-то

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