Dilma, а как мне запустить в динамике такую схему, что бы по циклу можно было опрашивать внутренние схемы ?
------------ Дoбавленo:

Или как после добавления выбрать именно ту схему, какую мне нужно в данный момент ?
------------ Дoбавленo:

Dilma, ну ё мое, неужели его нельзя добавить ?


Ну прекрасно он работает, только что проверил
------------ Дoбавленo:

Да, ну и где написано, что для запуска всех схем по циклу необходимо оформит точку ##doWork ?

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

Пробовал по имени выбирать -- фигня чистая, а ##Select работает согласно списка нормально

Dilma, ты чего молчишь? Идея добавить Select, открывает колоссальные дополнительные возможности полиморфа. Можно наклепать кучу схем в один мультик и вызывать их оттуда, когда надо и какую надо, и не обязательно все сразу.
------------ Дoбавленo:

Да, и заменить бы не мешало PoliEdit на PolyEdit

Не переживай, никто от select отказываться не собирается, более того, я даже предлагал сделать точку selectAll, чтобы можно было вызывать точки как для отдельной схемы, так и для всех сразу. Можно ещё предусмотреть для точки selectAll входной параметр - имя мультика, чтобы выбирать только схемы определённого класса.

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

А ещё, можно сравнивать частично, т.е. если у нас есть классы АБВ, АБГ, АД, ЕЖ то при параметре точки selectAll равном А выберутся схемы классов АБВ, АБГ, АД, а при параметре АБ - только АБВ, АБГ. Тогда для пустой строки выберутся все схемы. Кстати, установленный параметр selectAll, нужно при вызове точки сохранять в локальной переменной, чтобы обеспечить реентерабельность точек.

Ну ты и загнул...

мне не нравится, что системные точки сидят на самом элементе. #Add еще хоть как-то оправдано - типа метод для инициализации внутренностей, ну может быть ##select еще можно совместить с методом для дочерней схемы, но все остальное только мешает... Чуть позже напишу как бы это хотелось по другому организовать

Да, да, очень бы хотелось послушать. Элемент очень интересный по своей сути

Сегодня одно из больших неудобств при работе с динамическими контейнерами заключается в том, что необходимо при обращение к методу конкретного экземпляра схемы вызывать ##select перед его вызовом. Что в этом плохого?
1) ну очевидно мы делаем совершенно лишнее действие, а значит заведомо усложняем нашу схему на пустом месте
2) такой подход без специальной защиты может давать сбои при обращении к объектам в паралельных потоках(сегодня эта проблема весьма призрачна, но тем не менее)

Каким образом от этого можно избавиться?
Видимо выход пока только один: разнести всю кухню по разным элементам. Например так:
- основной элемент контейнер, который на этапе конструирования содержит в себе шаблоны схем, а на этапе выполнения программы - массив конкретных экземпляров объектов
- элемент управления массивом - обычный элемент не контейнер с точками doAdd, doDelete, doClear, doFind(вместо doSelect), событиями onAdd, onDelete, onFind и т.д.
- элемент Объект. Это скорей всего новая сущность в среде, которая представляет из себя простой элемент, чьи точки определяются по связанному с ним шаблону из первого пункта. На этапе выполнения это ссылка на конкретный объект из массива экземпляров объектов по первому пункту.
Несколько поясню на аналогии с ЯВУ

Это первый возможный набросок, который тем не менее не решает некоторые проблемы:
1) что должно происходить при обращение к точкам шаблона из первого пункта? (у нас все таки не ЯВУ и никаких классов как таковых нет)
2) как указатель из массива объектов будет попадать в конкретный элемент пункта 3? (т.е. кто и как реализует присваивание указателя переменной m)

Очевидно так же то, что с такой организацией надо делать внутри контейнера элемент, который будет обладать точками onCreate и onDestroy

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

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

По описанию очень похоже на то, что в своё время очень хотел AlexKir - указатель на объект.


А не показывать их вообще. У шаблона должна быть лишь одна точка снизу: template - интерфейс, с которым работает тот самый "элемент управления массивом", имеющий аналогичную точку сверху. Т.е. по этой связи мы передаём фабрику класса (в терминах СОМ)


А в потоке. Его выдаст onAdd или onFind, к примеру. А onFind, к примеру, будет возникать для каждого найденного.
Вопрос только, как сказать среде о том, с чем работает данный объект. Но тут может пригодиться технология менеджеров.

не похоже, а именно оно и есть. Назовем его ClassObject, чтобы не путаться далее.


ну да, тоже вариант впринципе...


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

Dilma, я доделал PolyMorph, но возник вопрос -- оставлять doWork для отработки всех схем по любому входному методу, либо сделать как в MeultiElementEx, только текущей, но тогда твой пример перестает работать, что тоже не интересно ?

делать все как в MultiElementEx, пример переделать.

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

Так и сделаю.
А по-умолчанию сделать одиночный или мультивызов схем