Это опять я со своим ООП.
Мне кажется в HiAsm нехватает сабжа.
На данный момент, динамический мультик - это коллекция одинаковых объектов с одинаковым интерфейсом (набором точек). Идея в том, чтобы иметь коллекцию разных объектов с одинаковым интерфейсом. Этого можно достичь, если позволить мультиэлементу иметь несколько разных схем (sdk в терминах редактора схем), переключаться между которыми можно было бы при помощи дополнительного набора закладок (появляющегося при заходе внутрь такого мультика). Имена и количество закладок (схем) определять списком строк в свойстве самого мультика. Эти же строки использовать при создании конкретного экземпляра посредством ##add, который считывал бы строку из потока (или индекс закладки).
Таким образом мы бы имели одну общую коллекцию разных объектов.

Возьмём такую задачу: простенький граф.редактор, в котором есть десяток разных типов объектов на поле, каждый из которых умеет выполнять десяток операций. Сейчас есть два варианта: засунуть все объекты в один динамический мульт, или сделать 10 разных мультов, по одному на каждый тип объекта. В обоих случаях не обойтись без десятка IndexToChannel с десятью выходами. В первом случае имеем огромный мульт, во втором - сложности с организацией перебора всех объектов, чтобы выполнить одну операцию для всех.

Новая фича в редакторе схем могла бы пригодиться и для нормального TabControl-а, который бы являлся родителем находящихся на нём элементов.

Я мало что понял..

МТ?

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

Да, это было бы очень удобно, а то мне пришлось заморочку применять, как ты писал

в котором ну никак мне не удалось обойтись без

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

такие правки внешне не очень сложные ведут к тому, что придется менять как минимум две вещи
1) формат SHA
2) интерфейс среды
3) кодогенератор

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

А получилось, аж три.


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

почему индексом? именем из выпадающего списка

1. формат SHA менять не надо, надо лишь иметь ввиду, что секций begin_sdk/end_sdk может быть несколько подряд
2. это понятно
3. и это тоже понятно, но достаточно лишь ввести ещё один параметр у elGetSDK, индекс схемы, а вызовы пока (до появления новой фичи) сделать со этим параметром =0

Кодогенератор, в принципе, сильно менять не надо будет. Надо будет сделать лишь генерацию всех схем, а в функции Create_hiMultiElementEx_XXXXXX добавить параметр dt:TData, передаваемый из ##add

Хорошо, а как это представляется при динамическом выборе


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


Вот, например, в таком случае

Схема определяется в момент создания экземпляра из параметра #add (либо имя схемы, либо индекс схемы), и в дальнейшем уже не меняется. Это же объект определённого типа! А выбор экземпляра останется как и полагается у динамического мультика ##select/##hselect.

ага, а это не изменение формата называется


нет, мне думается, что это будет все же новый набор методов. А по стандартному elGetSDK среда вернет первый экземпляр


так tsdima, сказал уже

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


я имел ввиду интерфейс в среде. Как - то же разработчик должен редактировать все это хозяйство.

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

а можно интерфейсно это представить и так
code_10425.txt

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


и как это должно выглядеть?

Есть же закладки с именами открытых проектов, сделать под ними ещё одну строку с закладками, которая появляется после входа внутрь такого мультика.

вот так?

только при большом количестве экземпляров не понятно, где это все умещать