2pkarklin
<You can’t define more than one form in a single unit. This is because each dfm or xfm file can only describe a single form (or data module).>
Спасибо за коментарий.
Однако, как Вы понимаете, здесь речь идет о другом - определение формы к юниту. Я же определяю формы совсем в другом месте :).
Кстати, сгенерить сколь угодно дочерних /и не обязательно дочерних/ форм из одного юнита - не проблема :).

Короче, никто с моей проблемой не сталкивался.
Извините, что отнял время и, если задел кого -то.
-------
P.S. Если кого-то интересует, как я сейчас решаю проблему, предлагаю кусок кода.
Type
TMyForm=class(TComponent)
private
new_form:TForm;
cnt_nom:integer;
public
property NewForm:TForm read new_form write new_form;
property Counter:integer read cnt_nom write cnt_nom default 0;
procedure Initial;
.............
end;

Не очень красиво - лучше напрямую наследовать из TForm, но как есть :)
-------------------------------
Еще раз - спасибо всем
P.S. 2tygra - не хами - читай вопрос внимательнее :)

2pkarklin
<Нет, я просто не могу понять идеологию построения такого проекта. Объясни, если можешь, как вы работаете?>
Попробую объяснить примерно так же, как в свое время мне объясняли.

Сначала скажу, что, естественно, описанный метод применяется не ко всем формам, а только к стандартным...

Одной из таких стандартных форм является форма "список значений ".

Базовая форма содержит Grid со списком значений, подписи, дополнительные фильтры, сортировку, вывод в Excel, FastRep, автоматическую подстройку размера и кучу других полезных вещей.
К тому же она в свой очередь может генерить подчиненную форму /экземпляр своего класса/. Например - при выборе из списка должников - информацию о клиенте или информацию о товаре или прайс или курс валют / все это - экземляры одного класса :) /.

Наружу "торчат" интерфейсы /события - наследники TEvents/, которые в зависимости от значения соответствующих свойств передают нужные параметры Data Module и получают нужный поток данных.

При подходе "одна форма - один модуль" мне нужно на каждый чих создавать свою форму /я даже не знаю число полей и понятия не имею какой глубины может быть drill-down/.

В случае динамической генерации "рутинная настройка" сидит в "базовом компоненте" - при использовании /например, подключении нового справочника/ настраивается только интерфейс доступа /в 90% - только на сервере/.

В результате "стандартная процедура drill down", занимающая в "классическом варианте" не менее часа /определить на каждый чих свою форму и в куче мест настроить размеры, события и т.п./ сокращается до 5-10 минут /создать экземпляр базового компонента/. настройка, как я уже писал, в большинстве случаев ограничивается сервером :)

2Hummers
<1. При таком подходе всеравно в Uses надо указать Unit главной формыБ
а значить или подключать ее source к проекту или использовать ee dcu.
2. А кто мешает создать Packadge этих форм и использовать компоненты из него?>
Отвечаю по порядку
1. Достаточно, чтобы был определен "верхний компонент".
"Внутренние" формы определять не нужно.
"Верх" является, например - компонент - "работа с объектом",
который сам при необходимости /выбор пользователя, сценарий работы,
команда сервера и т.п./ генерит нужную форму /список форм/ и т.п.
2. "Packadge этих форм" - число форм заранее неизвестно - они создаются
по мере необходимости /базовый класс один - нужные формы - экземпляры
этого класса/.
Основное удобство - при определение на сервере новой сущности не
надо ничего менять в клиенте.

2pkarklin
<Но если ты не создаешь для каждого справочника класс формы, порожденный от базового справочника, то где ты делаешь настройки типа ширина полей в гриде, кол-во полей, подписи полей, количество TEditов для задания критерия поиска, размешение доп. элементов, отсутствующих в базовом классе и т.д. Это все в коде делается?>
Есть 4 механизма
а) делается по умолчанию /анализируется поток данных и автоматически
подбирается размер/
б) делается запрос к серверу, который возвращает соответсвующие
параметры
в) есть возможность настройки на рабочей станции /отдельный разговор -
каким образом/
г) оператору дается возможность самому менять настройки /с
возможностью сохранения на сервер или рабочей станции/
------------
То же не совсем понятно, какие свойства и чего передают в DataModule? Где храняться компонетны с инструкциями на выборку\вызов хп, то же в коде? А что у вас со структурой хранения справочников. Ведь где-то дерево, где просто таблица, где-то N таблиц с группировкой. Или все под одну гребенку, чтоб компонент под справочник написать?
-----------
Все "сущности" прописаны на сервере /там есть описание свойств - кстати,
"экземпляры" одной сущности могут содержать разное число свойств разных
типов /. Соответсвующее описание - наш внутренний стандарт
представления данных на сервере.
------------
Но это же форма справочника создал, отладил и используй.
А так, используя "внутренние стандарты" добавление сущностей,
определение свойств и механизмы обработки - просто настройка сервера.
Не надо даже трогать настройки клиента /тем более перетранслировать его,
как Вы предлагаете :)/
-----------
Эх, глянуть бы на проект живьем.

Довольно затруднительно по следующим причинам
1. Серверная часть /объектная оболочка над MS SQL/ - примерно 20 тыс
строк кода + настройка под конкретный проект
2. Клиентская част - эксплорер - с учетом "базовых компонент" - примерно
200 тысяч строк кода
3. Технология использовалась на нескольких десятках рабочих проектов -
коммерческое ноу хоу :)

2Hammer
<Я все равно не понимаю кто мешает создать Package с ентим "верхним" компонентом и юсать его во всю?>
А формы динамически создавать?
Если да - то проще компонент определить.
Если нет - то для каждой формы нужен свой модуль...
2oleg_e
<Попробуй
tt:=TMyForm.CreateNew(Self);>
Именно на этом я и споткнулся вчера, когда переписывал одну базовую форму. Насколько я понял из цитаты pkarklin-а "в лоб" не решу, придется "обходить"..

2pkarklin
<Ну вот, теперь технология работы немного проясняется. :-) Хотя я таким заниматься не буду. Почему. Объектная оболочка эта канечна очень хорошо. Но... как же на счет оптимизации серверной части? Ну тоесть, если есть оболочка, то алгоритм ее работы жестко зашит в нее. А потом клиент - эксплоер. А я то думал, что это клиент в виде чистого ехешника, с MDI интерфейсом и т.д. и т.п. Вообщем понятно. Чувствуется коммерческий подход. Все в одну объектную оболочку... Мда. Я не говорю, что это плохо. Но я не представляю себе свой модуль Бухгалтерия в окне експлорера или структуру хранения данных модуля Технико-экономического планирования с процедурами расчета калькуляций и всего процего в виде объектной оболочки. >
Отвечаю по-порядку
- оптимизация сервеной части
На "простых" операциях /типа добавить проводку/ нагрузка на сервер
возрастает примерно вдвое по сравнению с "лобовым подходом" - не страшно:)
На отчетах, выборках и прочее - объектный подход сокращает серверную нагрузку на порядки
- модуль бухгалтерии
Модуль бухгалтерия /как и биллинг, и финансовая система, и штатное
раписание и склад/ на базе оболочки разрабатывается
"под клиента" - примерно 1 человеко-месяц /осовное занимает
"вылизывание" специфики/ - внедрение отдельный разговор /обучение,
ввод начальных остатков и т.п./

2pkarklin
<Демагогия, не поверю никогда. Если бы у тебя была объектная субд то да, а приладить объектную оболочку к РСУБД и так чтоб все летало... Тут блин днями сидишь, оптимизируешь, а ты на порядки... >
Дело в том, что объектная оболочка соптимизирована уже неплохо
/кстати, именно под такого рода задачи/
Если интересно, могу на пальцах объяснить, за счет чего :)
----
<Можно уточнить, что за клиент. Купи-продай... Месяц на рыбу еще куда не шло, а на законченный проект... >
На "рыбу" достаточно одного дня :)
На законченный проект нужнео месяц.
Однако, реальное внедрение, как я уже писал, занимает больше времени -
обычно, около полугода.
Если в процессе клиент хочет чего-то дополнительно, то
- 80% дополнений делаются "на ходу" - в пределах одного рабочего дня
- из оставшегося около половины занимает настройка "сущностей" и
связей - от 2 дней до недели /если уж очень многого клиент хочет/
- если нужно "переписывать ядро" (случается редко) - каждый раз
отдельный разговор /последний раз заняло около 2 недель/, года
два назад была перестройка на 2 месяца :)
------------
P.S. Я же говорил - производительность разработки /и, кстати, надежность и устойчивость/ взлетает на порядки - сам в свое время офанарел :)

2tygra
<Ты не сказал до сих пор - клиент на чем у тебя? Если IE - то в гробу я видал такую систему, даже если она сама себя настраивает :)>
Нет, IE я привел в качестве примера - как аналогия - есть эксплорер,
который и понятия не имеет о формах /виде, числе, количестве/ -
ему это приходит извне.
Клиент полностью написан на Delphi /почему, кстати, и такой объемный :)/

2pkarklin
<Давай, тока не на пальцах. А на каком нибудь конкрентом примере и в терминых сиквела, можно со структурой таблиц, бизнес-логикой. Кстати, где она у вас? Я не понял. Триггера там всякие, хп, понимаешь. >
От триггеров мы, практически отказались еще пару лет назад/отдельно могу часа два рассказывать почему/.
У нас есть точки входа-выхода на сервере.
Грубо говоря, есть процедура - которой на входе дается параметр
/отдельно есть так называемые "переменные окружения" /, а эта процедура
сама разбирается, что ей делать - где брать свойства клиента, экземпляры,
выборки и т.п.

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

<Надо нашему руководству про тебя расказать. Меня выгонят, тебя на работу возьмут. Не скромный вопрос можно? Опыт практического внедрения на промышленном предприятии имеется? И все-таки, каков круг клиентов? >
Отвечаю по порядку.
Думаю, нельзя.
Во-первых, инструментарий принадлежит не только мне.
Во-вторых, у руководителя группы есть свои амбиции - он позиционируется
не как разработчик, а, скорее, как финансовый директор.
Соответственно, он решает вопросы с коммерческими проектами.
Есть еще одна неприятность - часто кто-то из наших ключевых
сотрудников остается на проекте /народ дстаточно долго "врубается" в
технологию, затем, бывает, уходит/.
На моей памяти промышленности /производства/ не было.
Если ограничиться учетом, думаю, месяца на два-три разработки /предметная
область слегка новая/. Но, как всегда, основное время - внедрение.
А внедрение зависит не только от софта ..

Впрочем, насколько я понял, Вы справляетесь - новый человек всегда
достаточно долго "врубается в тему"

<Не принимай все ниже сказанное близко к сердцу, ладно.
Несколько лет назад завалился к нам распальцованный франчайзи 1с и сказал, да я весь ваш завод за пару месяцев с помошью 1с автоматизирую... Как ты думаешь, где он. Я не пытаюсь ни коим образом опаганить вашу систему, но реальный опыт работы на крупном Российском машиностроительном предприятии заставляет усомниться в твоих словах...>

Я, кстати, полностью разделяю скептицизм.
Особенно насчет "коробчатых продуктов" - проблемы и нашего софта
/тот же 1С, Абакус, Парус, Галактика/ и буржуйского /работали с Sun,Scala,
Platinum, немного видели SAP R3, Oracle Financial и Baan/ более чем известны.

На практике получается любой проект не столько разработка /сейчас она у
нас занимает обычно немного - от месяца до 3/, сколько внедрение -
"разгребание завалов", разбирательство, что на самом деле нужно клиенту,
организация технологии процесса /кто за что отвечает, кто что делает,
с кого какой спрос/. Тут бывает и полгода провозишься, и год /бывает -
больше/..

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

Тут недавно был проект. Компания всего сотни полторы народа.
Операций - тысяч двадцать в месяц, а полный цикл сопровождения длился
почти два года.

Большая часть проектов - услуги, торговля /приоритет - финансы, бюджет/.
Но с самого начала закладывались на масштабирование - не думаю,
что возникнут епреодолимые проблемы на поризводстве /по крайней мере,
совтовые/. Проектов на предприятиях более тысячи человек - штук пять.
А проблема организовать работу нескольких тысяч человек ИМХО на 99%
административные.

P.S. Кстати, изначально мы закладывались на работу на нескольких
серверах. Из последних проект крутится на 7 серверах + дополнительный
модуль - www /сбор данных с регионов/

Да, все-таки, мне у нашего PM еще учиться и учиться - опыта набираться.
Вчера позвонил ему, рассказал про проблему - он ее "расколол" сходу.

Сначала расскажу, как можно динамически создавать сколько угодно
любых форм с одним dfm на все про все.
1. Создается пустая форма /c dfm/, которая содержит только
дополнительное свойство /FormType/ и интерфейсы наружу /наследники
TEvents/
2. При занесении значения FormType динамически создается дизайн формы -
кидаются нужные колмпоненты, заносятся соответствующие свойства,
обработчики и тп
3. Для реализации 2. созда специальный компонент, который при вызове
соответствующей процедуры /занесении свойства/ разбирается какой
экземпляр формы создавать /или показывать/ с каким дизайном
4. В итоговом компоненте не нужно подключать ни ресурс 1.,ни даже 3.
/управление можно осуществлять через генерацию собственного события/

Да, все гениальное просто.
В принципе, можно обойтись даже без dfm - повесить интерфейсы управления
на стандартное событие TForm /например, на ONCreate/. Однако, по
некоторым причинам это не всегда удобно.

Так просто :)

P.S. Специально 2 parklin. Для любителей визуальной генерации форм.
Оказывается, в наших разработках используются два механизма
визуальной генерации динамических форм
а) Форма рисуется стандартными средствами Delphi и подключается
к специальному проекту - "шаблону", в котором есть кнопочка -
"Прочитать параметры". Сии параметры записываются на сервер -
и могут впоследствие использованы для генерации любых форм
/без перетрансляции прочих проектов/
б) создан специальный "конструктор форм", который входит в состав
базового компонента "администрирование" - позволяет настраивать
формы и записывать параметры в Run-time...
При таком подходе динамическое создание базовых форм становится иногда
даже быстрее, чем при "стандартном" - поскольку написаны специальные
процедуры, позволяющие, например, аккуратно изменять размеры форм /
автоматически выравнивая все компонеты/ и некоторые другие "фичи",
облегчающие жизнь разработчика.

Да, если наш PM занялся бы Вашими задачами, думаю, разработка Ваша
пошла бы много быстрее :)

P.P.S. 2tygra Кстати, ИМХО, как ни странно, динамическая генерация форм
в Run-Time является не "российской выдумкой", а стандартом Delphi.
Посмотри файл dpr - включение формы в проект и есть не что иное,
как вызов конструктора соответствующего класса. А возможность
вызывать такой конструктор не при старте проекта, а когда это реально
нужно и столько раз, сколько нужно, существенно расширяет функциональность :)

2pkarklin
<Не сочти за грубость, но я б такого PM с его подходом к разработке информационных систем даже близко к своей системе не подпустил (благо моя должность позволяет это делать :-)).>
Хозяин - барин /кстати, не думаю, чтобы он согласился :)/.
У нас новые сотрудники, пока не овладеют технологией, работают
в разы медленнее :)
<Ты что, считаешь, что у нас все формы автокриэйт??? Не надо нам прописные истины читать... Ваша универсальная идеология разработки понятна. Все под одну гребенку. Такой подход в серъезных проектах не применим.>
Не считаю и не собираюсь читать "прописные истины".
Просто удивила ничем неоравданная враждебность и хамство отдельных постов. А насчет "применимости в серьезных проектах" - вопорс более чем спорный - по нашему опыту подобная технология, как раз, оправдана именно на крупных проектах - на мелких накладные расходы съедают все преимущества. Но это так, к слову - можешь считать моим личным мнением :)