Здарсте...
воть опять затык возник не как не пойму.. многое перепробывал (скорей всего мало знаю или просто уже на работе мозги клинит..)
но ни как не могу приручить, так что после формирования формы ChildForm
RadioButtton выбрать можно было тока один ....
code_8382.txt

millano, проблема скорей всего в том, что эти радиационные бутоны находяться в разных понелях, а для того чтобы можно было выбирать один радиационный "бутерброд" из нескольких надо что бы они были в одной понели.
------------ Дoбавленo:

Можно зделать например так: Создай заранее, например, 30 "радиобутонов". У всех поставь Visible=False, Enabled=False И потом нужному количеству Радиобутонов устанавливай Visible=True, Enabled=True.

А если сделать так
Добавить на панель еще один вспомогательный невидимый RadioButton

При выборе проверять нахождение курсора(точка в прямоугольнике) и включать этот вспомогательный RadioButton

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

не последний вариант врядли подойдёт...
но можно попробовать..!

Dilma, ау

Это пример задачи, где помещение визуальных контролов в MultiElementEx не просто причуда, а конкретная необходимось

...MultiElementEx ...да это необходимо и будет быстрее и лучше.
что то ни чего не получаеться..help

Очень даже подходит
code_8392.txt

Прошу прощения за вопросики, раскладка подвела
------------ Дoбавленo:

И выбирать только мышью можно

оо очень здорово а я малёк не так подумал.... спс за пример....

Но утром-то, на трезвую голову, только одна мысль и остается - дурдом на каникулах

А с этим никто и не спорит
------------ Дoбавленo:

А вообще, в концепции Хиасма отсутствует одна из фич ООП: объекты могут быть созданы когда угодно и в каком угодно количестве. Поэтому и приходится плодить всякие там ChildPanelEx и иже с ними. В данном случае нехватает RadioButtonEx Можно, конечно, его сделать, но вряд ли это есть правильный путь - так, очередная заплатка.

Про "одна", думаю - ты погорячился

Скажем, Dilma выкладывал наметки на Дельфи-2
Так там всякий контрол (да и любой объект, наверное, с нетривиальным конструктором) приходилось "создавать ручками"
Если более внимательно подумать, то мы получаем базовое св-во у ВСЕХ элементов: Static/Dynamic (и, соответственно - метод ##add)

Ну и логика [FR]TCG должна измениться: конструкторы статических объектов запускаются раньше события Entry...
Известен же классический вопрос для CPP-шников: какие коды пользователя запускаются раньше первой строки в Main
С ответом: коды конструкторов статических объектов

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

Одни огорчения, в общем

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


Плодить именно панели не обязательно
Достаточно изменить концепцию с введением наследования: "погружение" (что это такое, и как это может выглядеть интерфейсно - предмет отдельных разборок) элемента в контейнер создает наследника, с автоматическим дублированием всех точек и св-в
И уже схемно эти методы и события можно переопределить, св-ва спрятать или добавить...
Т.е., в контейнере появляется "особый" элемент - предок
Так он и так уже есть особый... и обругивают его в INI так: Sub=Panel

Пока я как бы и не усматриваю особых противоречий, кроме отсутствия поддержки со стороны среды (которую еще сильно продумывать следует), и сопровождения в кодах...
А мы либо ждем пока кто-то продумает, либо верхние точки к какому-нибудь BlockFind добавляем