Я вот такой вот написал, но очень не нравится работа через панели. Как то не правильно это
Пример:
code_1758.txt

oldTV, а вот так не лучше -- метод неназываемого code_1759.txt

возможно в будущем будет некоторое интерфейсное решение на уровне среды, но пока только так и можно работать с данным элементом

Самое смешное, что более правильнее (БЕЗ НЕКОТОРЫХ ИНТЕРФЕЙСНЫХ РЕШЕНИЙ В СРЕДЕ) было бы сделать TabControl контейнером, а уже в нем были бы расположены необходимые панели.
Или просто контроллы с нужной привязкой, вместо панелей.
С "автоматической" установкой видимости, конечно.

В принципе, это сделать можно уже сейчас, но при этом будет необходим патченный KOL

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

Да нет. Можно обойтись...

Решение может быть таким (БЕЗ утверждений, что возможные интерфейсные изменения - это плохо):

Сам TabControl (который является парентом в контейнере) должен быть "пустым".

Странички он добавляет через InitMan по списку в св-ве Tabs

При этом у него должна быть верхняя точка - ControlsArray

Массив контроллов можно получить, если в элемент GetIndexData добавить фичу - нижнюю точку Array.

Ну и сделать нужным (а можно и всем) контролам нижнюю точку - Control

---

Уточнение:

а) добавление по второму пункту следует делать методом TC_InsertControl - он не является конструктором (в отличие от TC_Insert), а просто честно "регистрирует" нужный контрол.

б) Собственно не факт, что дочерними обязаны быть именно панели, что и достигается запросто в этой технике.

в) И тоже не факт, что все детишки обязаны быть "зарегистрированы" в табе... Все прекрасно работает и без этого. Пробовал (в "чистом" KOL - бодался ведь) так к примеру: "незарегистрированный" Edit с Align=caBottom, и куча "зарегистрированных" панелей с Align=caClient - прекрасно все работает.

г) да, и пустой TabControl правильней делать конструктором NewTabEmpty

nesco, лучше, спасибо, очень подошло
Dilma, очень жду будущего . Чуть чуть не в эту тему, но в тему работы со контейнерами. А Вы совсем отказались от идеи "регионов" в среде или пока отложили этот, сложный к реализации, подход?

все так, однако наибольшое число применений TabControl+Panels. У Borland такая комбинация называется PageControl. И именно про это мне кажется и было выдвинуто предположение в первом топике.


Каких регионов?

Так как будто такая возможность запрещается этим подходом.
И про название - никакой аллергии

А вот дополнительные методы в KOL (TC_InsertControl, NewTabEmpty, ...) появились как следствие идеологии "кодоэкономии" (моими молитвами, кстати)
А вот Borland-у эти соображения до потолка были, как всем известно...

Мораль: Borland - не есть верхняя кладезь мудрости

Значит совсем отказались...
Мы обсуждали тему "регионов" около полугода назад. Идея заключалась в том, что-бы уйти от "матрешковости" и реализовать контейнеры в раскрывающемся виде. Тогда можно будет перетаскивать элементы, скажем, интрефейса, с одной панели на другую, не создавая на новом и соотвественно удаляя точки на старом контейнере. С "регионами" среда HiAsm будет представлять собой единое пространство разработки.

я привел в пример только сам элемент, его название и функциональность. Как это реализовано уже второй вопрос. На мой взгляд реализация данного элемента в hiasm указанным выше способом - будет логична и правильна. Делать вставку через точки Control конечно можно, но назвать такой способ интуитивно понятным сложно.


вспомнил. Вроде проблему раздвигания элементов так и не решили тогда. Перемещение по контейнерам кстате будет реализовано в рамках менеджера проектов, который был во второй версии hiasm.

Интуитивно понятнее было бы, если бы если бы только верхняя сторона элемента была DPLE...
Без заморочек с массивами.

"Интуитивная понятность" - это прекрасно. Если не в ущерб правде

положим схемное решение будет таким. А каким образом предполагается все это редактировать в редакторе форм?

А вот тут как раз ничего нового - все как сегодня
Куча одинаковых контролов (скажем панелей), редактор формы показывает того, кто сверху
Что не самое удобное, и может не соответствовать действительности.
Да и caAlign может опять не очень соответствовать VCL

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



[size=-2]------ Добавлено в 20:00
Dilma, у меня тут test.dpr завалялся, когда я добавлял (какие-то фиксинги там еще были) эти методы в KOL...
Посмотри, чтобы понятней было - нет там "невидимых конструкторов", которые должны являться парентами других схем.
Все "видимо"
code_1763.txt

Рояль в кустах