Ну в принципе да, а сверху они некрасиво смотрятся, что-ли? Я, как-бы, предполагал их сверху...
------------ Дoбавленo:

Типа так:

А мне больше импонирует структура с вложенными мультиками, проще как-то, и нагляднее

открываем аукцион по этому вопросу...

Закладки

добавлена тестовая реализация полиморфного динамического мультиэлемента с возможностью наследования неограниченного числа сабклассов от одного базового класса. Проще говоря контейнер данного типа может содержать в себе множество схем, интерфейс которых полностью идентичен и определяется интерфейсом базового контейнера с именем base. В остальном все работает и выглядит так, как описано выше по топику. Разве что не все точки связанные с управлением контейнеров в RunTime еще определены.
Вот тестовый пример:
code_10491.txt

думаю из доработок первым делом имеет смысл добавить некий элемент среды, который позволит вызывать унаследованные методы от класса base.

Кроме того есть желание переделать логику работы с массивом схем, а именно расширить понятие "текущая схема" - т.е. если в качестве текущей ничего не задано, то любое doWork дублируется на все схемы контейнера. Это избавит от необходимости лепить внешние циклы для перебора всех схем контейнера.

Если есть какие еще дополнения по этому вопросу вписываем их сюда.

Я уже писал, что при варианте с табуляторами хуже визуальное восприятие, визуально непонятно, сколькоа схем в мультике, можно предложить область с квадратными иконками схем, по которым можно кликать и заходить внутрь -- альтернатива табуляторам.
А в остальном -- очень интересно получилось.

а картинку нарисовать?

Polymorph - полиморф [N]
Polymorphic - полиморфный [A]
Polymorphism - полиморфизм [N]
Polymorphous - полиморфный [A]

Что-то типа того (сам же сначала это предлагал)





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


Насчет ошибки правописания -- именно Polymorph, а не Polimorph

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

Dilma, еще вопрос -- а возможна ли связь между сабклассами
------------ Дoбавленo:

Да, еще -- а почему ничего не выдает базовый элемент, а ведь стоит выдать строку base worked

nesco, то, что лежит внутри любого динамического контейнера это всего лишь шаблон, по которому строится схема в RunTime. Если мы говорим о каких-то связях в них то должны сначала определиться, что это за связи и как они должны работать. Связь в классическом виде - Event-Work - не возможна тут физически.
------------ Дoбавленo:


потому что перекрытые методы базового класса не выполняются пока их явно не вызовет потомок - классическое поведение в ООП при наследованиях

Появилась ещё одна идея
Вообщем в Висте есть иммитация трёхмерных окон
Может и нам что то подобное
Только думаю это сложно-реализуемо

Пока писал вспомнил ещё про одну фичу для рабочего
стола.
Вообщем миниатюры окон.
При вставке мультика слева появляется ещё одна закладка
в которой скролом можно перемещять миниатюры.
Вообщем панель такая же как сейчас Elements
Только там мультики .

Понял

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

вот еще интересный пример:
code_10493.txt

тут оба наследника имеют общий код ввиде рандомов, которые генерируют случайные координаты для объекта. Обычно такой код выносится в protected метод или в конструктор базового класса, а результаты его работы сохраняются в protected полях, которые затем используются в потомках. Реализовать такое более менее адекватным образом сегодня можно только через аналоги GlobalVar, но действующие исключительно между base кслассом и его потомком. Т.е. примерно такая схема получится:
code_10494.txt

nesco, считай, что это так же пример одного из видов связи, о которых я говорил выше.