Повторюсь, постом Galkov'а призвано воду в ступе не толочь. Ибо не разбирая о чем разговор, достаточно привести пример, не объясняя зачем, оговорившись - тем кто попытается вытащить Edit из любой из панелей на вкладке FLASH - надо просто бить по рукам. Зачем пример проводили, Galkov? Что бы я попытался переместить Edit из любой панели на вкладке FLASH? И Вы потом ударили меня по рукам?

Затем, что Вы, уважаемый, подумали над его содержимым.
Собственно, я всегда именно с такой целью примеры выкладываю.

Если это напрягает - извините, не настаиваю

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

выглядят более разумными

Dilma, всю отладку надо как-то в плагин перенести.
Чтобы именно он разбирался с содержимым "буфера", формировал команды обмена....
Глядишь, и с MT что-то адекватное придумается...

Да и кнопкам управления отладкой место именно на панели Debug, вроде - кому они нужны, пока отладка не запущена...

смысл?

Чтобы отделить развитие среды от интерфейса.
Не ее дело, кажется, разбираться в MT, типах данных, в наборе команд отладки

Разделение труда, в общем
И не обсуждать потом больше никогда: поле вывода - это Label, или Edit

[size=-2]------ Добавлено в 15:42
Предположим, приспичило как-нибудь потом изменить формат данных в том самом Buf
В этом случае можно произвести синхронные изменения в Debug.pas, и кодах элемента из плагина, который за это отвечает.
Не торогая среду

C точки зрения интерфейса - страшно смотреть Ваш пример. За такие интерфейсы я бы не только руки отрывал, еще и ноги и спинной мозк. Зачем остальное я не понял. А видимо раз не понял ВАШУ глубокую мысль, значит и разговаривать со мной нечего. . Спасибо хоть снизошли до такого...

Или Вы хотели, что бы я понял, что премещать Edit из любой панели во вкладке Flash нельзя? Так я не понял. Что в Вашем Edit'e особенного такого, что он, Edit, не может быть в другой панели? Edit - элемент интерфейса, где захочу, с точки зрения функциональности его видеть, там он и будет. Доведите неразумному смысл приведенного Вами примера. Вдруг дойдет. Должно дойти.


Спасибо

P.S. Бедный Edit, прицепились к нему, прям жалко аж...

[size=-2]------ Добавлено в 18:08
хотя нет... мысль понял: удаляешь элемент из контейнера 1, удаляется он же из контейнера 2. Фича HiAsm? Супер... Понадобится в будущем, спрошу как делать...

Меня не интересует Ваше мнение о интерфейсе. Я прекрасно проживу не зная его.


Если ты изменишь любую панель, и, соответственно - схему на вкладке Flash, перестанет работать схема на вкладке EEprom.
Вот такая вот особенность в нашем Edit'e.
И утверждение состоит в том, что не только в нашем, и не только в Edit'e

---

oldTV, Вам следует научиться просто ЧИТАТЬ написанное. Не писал я про аналогию с элементами ради понтов, а лишь потому, что это так и есть на самом деле.

Все это я УЖЕ объяснял раза так - три.
А и сейчас не уверен, что дойдет.
И что характерно: кому от этого хуже станет - уж точно не мне

[size=-2]------ Добавлено в 18:11

Я говорил Вам про это с самого начала, но Вы не с состоянии были адекватно воспринимать информацию.

Но, Galkov, матрешка, это что хорошо? Показали вы сейчас некую фичу, которая видимо работает в связке работы с панелями и вкладками. Изначально речь была в другом. Вы теперь возьмите мой пример и переместите Edit и 1й панели во вторую. Засеките время. Представьте разнообразие пришедших в первую панель связей. Представьте сколько понадоится времени, чтобы из одной матрешки, перенести в другую. Отвлекитесь от панелей. Вольмите мультик. Там таже песня с хомячком и черепахой. Как еще объяснять Вам Всем что это неудобно. Видимо никак...

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

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

И именно таким образом следует распределять ф-и по мультиэлементам.
И только после этого станет возможным собирать схемы неограниченной сложности.
Опять же давно уже (по результатам - без пользы) приводил пример: в схеме ElementsDelphiExampleDrawFifteens.sha я могу заменить мультик <Заполнение матрицы случайными числами> на свой, с генерацией ТОЛЬКО собираемых комбинаций. И у меня нет никаких сомнений, что если мультик работает правильно (в другой тестовой схеме), то и все схема БУДЕТ работать правильно. Именно это называется устойчивостью, каковым оно на самом деле сегодня и является.

Более того, это не мы придумали - в этом смысл ООП. Или по другому: Объектно Ориентированный Дизайн - есть и такой термин.

И ваши предложение отказаться от "матрешковости" - это отказаться от принципов ООП.



Я показал фичу для абсолютно всех элементов - измени код в одном, изменится функционирование всех экземпляров этого элемента.



Я не хуже Вас разбираюсь во времени.
А еще мне известен самый главный принцип экономии времени: сначала ДУМАТЬ, а уже потом делать.

Знаете, Galkov, не надо поспешных выводов. Ни от каких принципов я не призываю отказываться. Тем более если они обеспечивают, как Вы заявлеете, устойчивость программирования. Спасибо им. Более того, Galkov, раз контейнеры неотемлимая часть и без них нельзя - как я могу призывать от них отказываться? Вы видно просто не понимаете мою идею...

Поясните, чем Edit находящийся вне панели (без Ваших фич только, они для гуру) отличается от того же самого Edit находящегося внутри панели? Следуя из подробных разъяснений принципов ООП выше, Edit наследует класс той панели, в которой он находится. Да?

Видимо вы все же друг друга не понимаете

oldTV, не предлагал переходить на некий новый уровень представления контейнеров в коде. Даже более того - в последнем варианте и с точки зрения интерфейса остается все по прежнему. Им было предложено всего лишь развертывание контейнеров на рабочем поле без непосредственного входа в них для того, чтобы иметь возможность сразу перетащить элемент на уровень ниже или выше. Грубо говоря заменить последовательность операций Ctrl+X -> Backspace -> Ctrl+V на одно перетаскивание мышкой с автоматическим сохранением связей.

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

Dilma, спасибо.
Если уж не получится автоматическое сохранение связей, может все таки развертывание контейнеров на рабочем поле сделать? Так хотя бы всеже будет видно куда тянут... Связи... А потом может быть и неоднозначности рассеются

Ага тупой, уже год, как не понимаю.
Того, что такие идеи могут возникать только в понимании контейнера - как коврика.
Каковым он НЕ является.
ДАЖЕ, абстрагировавшись от внутренного представления.
А если будет являться - HiAsm на этом и закончится.

И того, что собственное его понимание является главным, и как следствие - "да не лезьте вы ко мне со своими глупостями, а то умные шибко"

---

Собственно я наступал самостоятельно на последствия "последовательности операций Ctrl+X -> Backspace -> Ctrl+V" (у меня и еще линкованные мультики есть)
Не самый простой вопрос - потом ошибку найти.
Времени это занимает значительно больше, чем подумать перед перетаскиванием.
Вот над этим подумать как раз и следует

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

А я вот тоже в толк не возьму -- как может схемное построение (кодировка sha), до вступления в силу кодогенератора, повлиять на перетаскивание компонентов? Схема -- еще не код, а просто набор различных дескрипторов. Удалил компонент, он вместе со своими дескрипторами и исчез, вставил -- появился.