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

для -=Alexey=-:
> ...т.е. когда не известно как должна выглядеть форма
Очень просто! Герерите случайные числа и создаете по результатам контролы, заполняете их свойства опять же случайными числами - вуаля! Получится то, не известно что
Или все же известно? Т.е. нечто или некто должен все-таки настраивать заранее определенный костяк?
Задача действительно не ясна. То ли создание собственных мастеров (действительно, иногода оч.полезная штука), то ли создание интерфейса "на лету" (а юзер ждать не запарится?), то ли еще что...

>P.S. я просил поделиться опытом, тех, кто с этим работал
С чем? Уточните пжалста...

Нервных попросю удалиться... (Программерам со стажем более 3-х лет читать не рекомендуется :)

Вариант 1:
Динамически создавать форму по принципу мастеров, при этом в период времени между "открывающими" фому действиями юзверя и непосредственным открытием формы - показывать юзверю мультики...
Достоинства: "и нефик голову ломать"...
Недостатки: только mdb/adp, тормознутость (в момент создания и в момент исполнения кода формы, который останется некомпиленым), глючность (создать форму в скрытом виде, повтыкать контролы в форму и код в модуль, завязать события - навряд ли получится решить в лоб и без глюков), постоянный рост файла интерфейсной части БД и т.п.

Вариант 2:
Создаем "костяк" - несколько форм с заранее (с запасом) понавтыкнутых в них нужных контролов, которые на лету настраиваются в соответствии со списком атрибутов.
Достоинства: Побыстрее (на несколько порядков) 1-го варианта.
Недостатки: Недостаточная гибкость при мало-типизированных НАБОРАХ атрибутов в сущностях.

Вариант 3:
Формируем на лету текстовое представление атрибутов и их свойств, вываливаем юзверю на форму (в ричтекстбоксе) и позволяем просматривать что-угодно и, соответственно, менять что угодно.
Достоинства: Аб-со-лют-на-я гибкость :)
Недостатки: необходимость организовывать синтаксический разбор и... объяснять юзверю, что менять нужно только то, что написано жирным (курсивом и т.п.).

Вариант 4:
Создаем форму (главную форму) с понавтыкаными в нее не связанными подчиненными формами, т.е. просто контролы подчиненной формы, не привязанные к конкретным формам. Создаем формы с какими угодно фильдеперсовыми контролами (формы-контролы), отображающими ОДИН атрибут (на одну форму - один "контрол/составной_контрол"). В момент открытия главной формы втыкиваем в наделанные с запасом контролы подчиненных форм какие угодно формы-контролы.
Достоинства: максимальная гибкость до момента, пока кол-во атрибутов не превысит кол-ва заготовленных на главной форме подчиненных "окошек".
Недостатки: и как эти самые формы-контролы подключать к данным? Программно, наверно...

Вариант 5:
ТриВью :) Отображать значения атрибутов прям в дереве, а по двойному клику открывать всплывающую форму с необходимым контролом (для редактирования значения атрибута)

Вариант 6:
Объяснить "админу", что его вкус компутер понимать отказывается и... поступить по 7-му варианту, который, не сомневаюсь, предложит All :)

Вариант 7:
Вставить в форму IE-вийвер и формировать html на лету, подсовывая его потом в этот самый активХ - и контролы какие хош и скока хош и оформление на уровне и скрипты, опять же. Самый-пре-самый клевый вариант, кажется :) А?

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

>Я, конечно, человек малограмотный и дремучий, но мне кажется, что заданный вопрос чрезвычайно интересен. Лично мне надоело рисовать формы (и отчеты) в графическом интерфейсе, тем более, что они почти все одинаковые (или похожие). Единственное, чем они отличаются - источниками данных для связанных контролов и процедурами обработки событий. Было бы гораздо интереснее создавать формы кодом на основе каких -то шаблонов. Формы ведь для чего нужны? Чтобы показать/засунуть то что лежит/не лежит в БД.
Нуф-Нуф, А нет ли у Вас варианта кода форматирования к-л формы ( на основе к-л случайной структуры данных) из предложенных Вами вариантов для оценки реальности применения данной методики?

Для wara:
Сразу должен оговориться, что предложенные варианты - не более чем "мозговой штурм". Любое универсальное решение, предложенное для решения конкретно поставленной задачи будет так или иначе уступать узконаправленному (на эту задачу) решению. Поэтому, если вам необходимо выполнить простую задачу, то не стоит пользовать "динамические интерфейсы". А вот в контексте данного топика (покажи то, еще толком не знаю что) простые (типовые) решения мало применимы, поэтому и приходится "штурмовать". Хотя, имхо, любую задачу необходимо пытаться свести к типовой (например: Задача: Разделить поровну 0,8 л водки на троих. Решение: налить каждому по 100 гр, после чего задача приводится к типовой, т.е. 0,5 л на троих :)

>...тем более, что они почти все одинаковые (или похожие)
Лично я для "почти одинаковых" форм и отчетов создаю шаблоны, которые активно и пользую - копирую их в БД, переименовываю и вперед... И без всяких там мастеров :)

>...гораздо интереснее создавать формы кодом...
Именно так и поступают супер-крутые программеры, которые лобают непосредственно на ВинАПИ. Но только представьте себе, что для создания элементарной кнопочки на форме вместо клика-перемещения-клика вам необходимо написать десяток строк кода, с описанием где-что-как-какое! Графический интерфейс призван не столько облегчить разработку программ, сколько увеличить ее эффективность (имеется в виду экономическая эффективность).

>А нет ли у Вас варианта кода...
Дык... Какую его часть из десятка модулей (классов)? Т.е. вобще-то я в большинстве случаев пользую самый не динамичный интерфейс, но у меня есть грид на основе ленточной формы, который полностью настраивается динамически (от, в некоторых случаях, связывания контролов с источником данных, до цвета границы контролов). Сия система реализована по второму варианту (см.выше), при этом только настройка внешнего вида грида в соответствии с настройками Разработчика и Юзера производится посредством примерно 700 строк кода (естественно, не все выполняется, поэтому работает быстро даже на приторможенных машинах), а ведь еще надо:
Хранить настройки Разработчика/Администратора/Юзера
Загружать настройки в комутер (формирование объектной модели)
Подключать Целевой грид к одной из Опорных форм грида
Настраивать Опорную форму в соответствии с настройками Целевого грида
И т.д и т.п... Шо-нить конкретно?

мля :((( Сорри за полное цетирование wara - так получилось :(

>Надо топик было назвать "Динамическое создание ТЗ"
Для тех, кто не знает что такое "ТЗ" поясняю: "Траблы Заказчика" :) Итого имеем " Динамическое создание Траблов Заказчику "

Похоже, автор топика выбрал 6-й вариант, а не 7-ой (Лох Позорный спасибо за оценку :) Хотя вообще-то я не догнал, как можно " договориться не делать такого интерфейса "? Не "ТАКОГО", а "НЕ ДЕЛАТЬ" :) Т.е. если предметная область требует наличия в принципе не ограниченного набора атрибутов для описания сущности, то как можно сие обойти и не делать ИНТЕРФЕЙС? Через приведение задачи к типовой (пол-литра на троих)? Тогда было бы интересно услышать об этом самом "приведении" :)
А?

Уговорил!!! Наливай...

ААААААААААаааааааааааааа!!!!!!!!!!!!
ЗЕМЛЯКИ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
//кидается на MiCe