Мысль есть
Сделать контейнер "Фиктивная панель"
Попросим nesco нарисовать красивую дулю в качестве иконки.
А в кодах этой "панели" будет стоять пустышка, только и передающая parent-а остальным визуальным контролам.
И пущай среда считает ее для себя настоящей... Если уж она без этого не может никак...

С динамическими радиобатонами, к примеру, вопросы закончатся

Ну дуля -- это как-то не солидно , ну что-нибудь придумать можно...

nesco, Можно фигу.

помоему имеется неполная ясность того, что тут обсуждается. Любой элемент в среде представлен INI файлом и что значит "создавать еще один" не понятно.

Скажу честно, не надо всетаки, хотя конечно было бы удобно

наверное тоже, что и при применении SQLite иметь еще и tabs.ini

Tad, вообще-то, речь идет примерно об этом: http://hiasm.com/forum.html?q=3&p=74711
Ну или одним постом выше, от nesco
Да и предысторию почитать не бессмысленно (речь о новых INI не идет)

Один из тех самых случаев "не конкретных предложений", после которых как-то не следует вопросов для разрешения "не конкретности"

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

Вот смотри сюда....
Вообрази себе, что есть один могучий объект - Bitmap. Именно в нем содержится как память для картинки, так все 156 рисовальных методов.
Так вот, тот элемент Bitmap, который есть у нас, это элементарный его наследник, у которого оставлены только методы "хранителя"
А остальные элементы (естественно, при DrawSource=Bitmap) из вкладки Графика - это указатели на объект этого класса, которым оставлены только нужные интерфейсы.

Аналогично и со стримами...
Только главный элемент там не конкретизирован: методы чтения, записи, и т.п.. - абстрактные. По нашему, по-хиасмовскому - не подключены необходимые обработчики к верхним и правым точкам.
Вот, а у его конкретных наследников (MemoryStream или FileStream) с этим все в порядке уже.
Так "указатели-то" на объект (DataToFile, DataToFileEx) - указывают на вышеупомянутый главный объект

Вот тебе и наследование, и инкапсуляция, и ее успешное применение...

К чему я это, отгадай.
Да к тому, что этот главный элемент, это мой мультик у которого, скажем, 43 точки
Как я им сегодня пользуюсь
Правильно - очень-очень много связей разных калибров буквально со всех мест схемы. Туды-обратно, обратно - снова туды...
Ну представь себе, что у тебя в схеме под сотню рисований, а все рисовальные точки находятся только на элементе Bitmap - источнике картинки. Вот тогда примерно получится моя схема
А я хочу со всех мест схемы тянуть один "хэндл"
Аналогично вышеописанному (затем, собственно, и описывал).

---

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

так и я почти об этом, толко если вы предлагаете создать в ini секцию исключений , я предлагаю эту функцию возложить на ECreator (и разработчика) и создавать "полновесный" ini- файл со всеми нужными свойствами и с скрытыми точками отсортированными по именам. Сейчас найти нужную - только перечитав все. не возмущает он (факт наследования) меня, просто считаю, что, например,
1. WinControl.ini должен использоваться только ECreator-ом на этапе создания или редактирования компонента,
2. у "рабочего" компонента в папке conf должен лежать "полновесный" ini- файл со всеми нужными свойствами
3. не заставлять среду анализировать - это свойство ЕСТЬ или НЕТ

После одного изменения в WinControl.ini ты предлагаешь пройтись по всем штатным контролам с помощью ECreator-а
Не говоря уже о не штатных

Ну и вообще-то есть желание, что-бы мультик (или иное аналогичное средство) выполнял роль таки ЭЛЕМЕНТА, и это было доступно пользователю не знакомому с священнодействиями автора элемента-предка.
Каждый должен висеть за свое яйцо... Вроде бы...

Кстати говоря, в моих предложениях по этому топику было не просто 100-пудовое наследование, но и обязательные возможности инкапсуляции.
Без второго, это уже совсем не мое предложение будет.

Ну скажем, есть у нас хитрые возможности пользовательского сравнения для сортировки в StringTable
Прилепляем свою специальную продуманную схемку и погружаем в контейнер-наследователь. Совершенно естественно, что точек типа ExtCmp, doSortExtCmp - не должно появляться снаружи
По идее, только, чего тебе надо и должно остаться.
И чего, в такой пользовательской технике, ты предлагаешь ECreator применять

Примерно такое я имел ввиду, когда говорил про "перекрытие абстрактных методов в главном Stream-е"
Аналогичная техника могла бы позволить делать "обыкновенному пользователю" данные типа Array, Matrix, и т.п..
Глядишь, и знаменитый элемент коллеги nesco удалось бы привести к нескольким уже воспринимаемым профилям....

Galkov, ну вроде Dilma предложил идею MakeElement'a. В нем можно сохдать свой элемент со своими точками. Все упирается в создание мультика "прозрачного" для WinControl'ов. Может, все же, пойти путем, который ты и предложил, про "фиктивную панель" (мне больше нравится -- нуль-мультик)

nesco, ну вроде бы именно там есть некорректности, и как бы есть ответ на одну из альтернатив этого запроса:

Вот ссылочка, чтобы не быть голословным: http://hiasm.com/forum.html?q=3&p=82181
И чего дальше
Адаптировать коды глупо из-за отсутствия интерфейсного сопровождения, интерфейсное сопровождение не делается то ли потому, что нет этих адаптированных кодов, то ли потому, что нет некого Evgig-а в качестве переводчика
Не знаю... По вышеприведенной ссылке установить это затруднительно.


Хотя делов-то...
Задача разбивается на две части: именно интерфейс пользователя, и вернуть в CGT некие флаги для каждого св-ва.
Второго - вполне достаточно для работы с кодами.
Вот тебе, лично, там все понятно Если нет, то чего не спрашиваешь, не пойму...

Ну хорошо, пусть (предположим !!!) выполнен только второй пункт, про флаги.
Мы шустренько сляпаем код, который честно и благородно для пустой формы отрапортует в окно Debug: "property MainForm_4DF8F48._prop_Left - is ingored"
И так 25 раз из 28, для MainForm (это еще сплитер не приляпан, было бы больше)
И что характерно - все было бы правильно и законно.

Как должен реагировать нормальный человек, на такие "разумные и трезвые" сообщения
А он "нахально и дерзко" должен спросить: а чаго вы тогда народу мозги парите на панели св-в
И будет прав.

---

BTW: Что такое прав и что такое не прав...
Конечно могет возникнуть разночтения по этому вопросу.
В таких случай следует не рвать рубаху на груди, или обижаться на всю жизнь, а переводить
диспут на более абстрактный уровень.
В данном случае, это прояснение целей и задач совершаемого действа.
Если по этому пункту есть разночтения - еще выше.
Если это "выше" кончилось, беседу следует заканчивать, в виду ее полной бессмысленности. ИМХО.

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

А что, если пойти по пути предкомпиляции пакета при добавке нового компонента. Среда предкомпилирует компонент, эмулируя все возможные подключения и определяет, что можно оставить в *.ini, а что оттуда убрать и генерирует новый *.ini, добавляя в него работающие базовые методы и методы, прописанные создателем. Ну это так -- бредовая идея в голову влезла.

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

Скажем делаю я некий пакет и в какой-то момент хочу добавить для программ моего пакета локализацию на уровне среды. Как я себе это представляю?
1) В палитре свойств элемента должна появится новая команда ввиде пункта меню с галочкой на св-вах типа data_string с названием "Перевести".
2) в палитре элементов хочу заиметь элемент среды с названием Translator и двумя св-вами: Lang - имя языка, LangWords - массив именованных элементов типа string
3) хочу, чтобы во все элементы данного типа попадали все св-ва со всего проекта помеченные "на перевод", чтобы пользователь смог вписать туда свои переводы(прочие взаимодействия с пользователем сейчас не важны)
4) хочу иметь в cgt метод, который вернет true, если св-во помечено на перевод и false в противном случае:

Иной стиль изложения идей будет приниматься как "пища к размышлению" без каких-либо изменений в среде и её интерфейсах.
------------ Дoбавленo:


такое только в рамках FTCG сделать возможно. Вообще по скрипту hws с некоторыми правками можно практически полностью восстановить конфигурационный ini

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

Зато возможно узнать и заблокировать явно неработающие методы, такие как onPaint, например, приводящими к ошибкам. Это все в качестве дополнительного контроля.

есть более рациональное решение: убрать onPaint из WinControl и вписать его там, где он нужен