Уважаемые господа!
Помогите, пожалуйста советом.
В Run-time я создаю различные экземпляры класса TForm.
Теперь я хочу определить свой класс - наследник TForm.

Трансляция проходит без проблем.
Однако, в процессе вызова конструктора мне выдается сообщение об ошибке - нужен ресурс.
Могу ли я обойти эту проблему?

Заранее спасибо...

2tygra
<Все правильно - dfm то нет для этой новой формы :)) >
Забавно, но Tform.Create(self) проходит без проблем.

Насчет цели - у меня в клиенте по мере необходимости создаются
формы /часто из используемых компонентов/.

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

2Memento
Вы можете уточнить Ваш совет.
Дело в том, что для базового класса у меня нет dfm -
только источник pas ...

2pkarklin
<В дельфи одна форма - один модуль.>
Это не совсем так :)
В большинстве моих клиентов модулей 3-4, а форм может быть сколько угодно /зависит от сценария работы/ - обычно порядка 15.
Кстати, очень мощный, удобный и функциональный механизм получается :)

<А это вот как это, из используемых компонентов, а?>

Компонент

Type
TNewPanel=class(Tpanel)
private
new_frm:TForm;
public
property NewForm:TForm read new_frm write new_frm;
procedure SetFormParams;
----
procedure RunNewForm(AOwner:TComponent);
end;


procedure Register;

procedure TNewPanel.SetFormParams;
begin
if NewForm=nil then exit;
NewForm.Top:=... ;
end;

--------------------------

В процессе работы - пусть, компонент уже на форме
tt:TNewPanel;

procedure TWork.ExecPnl;
begin
if tt.NewForm=nil then begin
tt.NewForm:=TForm.create(self);
tt.SetFormParams;
end;
-----
Новая форма создается только тогда, когда нужно -
параметры и управление передается корректно :)

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

2pkarklin
<Да уж, круто. Такого я еще не видел. Меня тока одно интересует. А нафига так делать? Ну всмысле фичи какие???>

Очень удобный подход.
Могу сказать, как он возник.
Я орбнаружил, что часто мне нужно вызывать однотипные формы из совершенно разных мест - списки выбора, шаблоны редактирования и пр...
Когда число проектов стало измеряться десятками, тащить все dfm,
править их и соображать, кто вызвал становилось все утомительнее.
Возник прием - один раз прописать все в Run-time, затем создавать по мере необходимости.

Сначала я пользовался наследником TPanel. Потом убедился, что часто
TForm удобнее.
А уж засунуть генерацию формы /иногда список сгенеренных форм - наследник TList/ в свой кмпонент - дело техники.

А на след шаге споткнулся - создавать экземпляр TForm в Run-time могу,
определять свой класс - наследник TForm - тоже. А создавать экземпляр своего класса не выходит.
Вот и прошу помощи - может, у кого будут идеи?

2Mermento
<Создай форму нормально, средствами Делфи (вместе с DFM),
а потом от нее наследуй свои (в том же Unit).>
Спасибо за совет.
Я иногда так и делаю.
Проблема возникает только в том, что я должен всегда добавлять в проект исходник /при числе компонент несколько десятков/ - становится нетривиальной задачей - не забыть в новом проекте добавить все нужные исходники /в моем примере прекрасно обхожусь без этого/.

2parklin
< Вместо того, чтоб научиться правильно управлять проектами, использовать в разных проектах одни и те же формы, вы придумали, на ваш взгляд, удобный подход>
Зря вы сердитесь.
Я довольно давно работаю с Delphi, умею управлять проектами /по Вашей терминологии "нормально"/. Просто, натолкнувшись на ограничения и неудобства "стандартного подхода", использую приемы, ИМХО более удобные.
По крайней мере, существенно более эффективные, чем "стандартное управление проектами" :)

2tygra
<А мысль не приходила (наверное нет:)), что указать в uses имя файла с формой и использовать ее где хочешь и откуда хочешь, и она может быть хоть откуда, хоть из другого проекта, хоть сама по себе - ну, это же слишком просто, так настоящие программисты не делают. >

Вы совершенно напрасно нервничаете и невнимательно читаете вопрос.
Я уже писал почему неудобно <указать в uses имя файла с формой и использовать ее где хочешь и откуда хочешь>.
Повторю для Вас еще раз В КАЖДЫЙ НОВЫЙ ПРОЕКТ НЕОБХОДИМО В ЯВНОМ ВИДЕ ВКЛЮЧАТЬ ИСХОДНИК, ЧТО СОЗДАЕТ ПРОБЛЕМЫ СИНХРОНИЗАЦИИ ПРИ УСЛОВИИ, ЧТО ТАКИХ ИСХОДНИКОВ - ДЕСЯТКИ
Если Вам не нравится используемый прием, можно просто сказать и не ругаться. Я не навязываю свой подход, а прошу совета, если Вы, как специалист можете его дать.
Ваш ответ /обязательно dfm файл/ был некорректен.
Может, на форуме найдутся специалисты, которые могут ответить правильнее.
Возможно, мы не поняли друг друга.
Не понимаю, почему Вы скатились на личные выпады в ответ на простую просьбу о помощи - не хотите помочь, достаточно было проигнорировать вопрос или прсто сказать об этом :)

2tygra
<А может про неудобства "стандартного подхода" заодно расскажешь - а то мы тут темные, всю жизнь работаем и не знаем, что неудобно это. >
Думаю, эта фраза - поытка съязвить /ИМХО крайне слабая и неудачная/.
Я пытался объяснить свое мнение /возможно, неудачно/.
Если Вас это мнение, действительно, интересует, могу постараться объяснить лучше.

2pkarklin
<Дилетант, прокоментируйте, пожалуйста, что значит в явном виде включать исходники и какие при этом проблемы синхранизации. Если вы копируете в новый проект форму, которая уже создана и используется в другом проекте, вместо того, чтоб в обоих проектах использовать одну и туже форму, тогда да.>
В разработках, как Вы написали, используются два подхода -

1. Базовые формы /на данный момент их порядка 30/ копируются
в каждый проект
2. На некоторых проектах используются общие формы

Могу объяснить, почему 2 подход используется довольно редко
- не всегда к исходникам есть доступ с различных рабочих мест
/реально, в проектах участвует 3-4 разработчика, да и я сам использую,
как минимум, 3 машины - на работе, notebook, домашний desktop/
Понятно, что при такой конфигурации использоавть один исходник
невозможно
- Использование одной формы в разных проектах потенциально может создать
"глюки" при перекомпиляции других.
Например, при добавлении на базовую форму нового компонента /скажем,
TLabel - подпись/ в предыдущих может не быть процедур обработки - на
формах появляется "мусор" (приведен крайне тривиальный пример,
реальные проблемы синхронизации серьезнее).

Гораздо эффективнее динамическое создание /в том числе и упомянутого
TLabel/. Есть процедура создания, которая определяет, когда нужно
создавать необходимые компоненты с какими свойствами и куда их
помещать на форму.

Я не понимаю, почему такой подход вызвал бурю возмущения.
Реально многие базовые компоненты созданы года два назад /я уж про
большинтсво мало что помню - только основные интерфейсы
взаимодействия/. Зато я знаю, что для нового проекта достаточно поместить
/чаще создать :)/ один компонент, который при необходимости сгенерит
нужные компоненты и формы, когда это потребуется.
Это много удобнее, чем держать в голове взаимодействие десятков
компонент и каждый раз тащить их в проект. Еще один плюс -
я могу отдать компонент другому разработчику /или взять его компонент/,
который использует кучу "базовых". При этом мне достаточно представлять
только 3-5 свойств и пару порцедур, а не разбираться в чужой логике
построения базовых компонент.

Если мы используем объектный метод, создаем свои компоненты из
существующих, то почему такой протест вызывает использование таких
"родителей", как TPanel /удивление tygra/ или TForm?
Эти компоненты ничем не хуже других - и иногда их использование
оправдано - это зависит от конкретного случая.

P.S. В этом форуме как-то тусовался один из нашей команды /кстати, я
здесь по его совету/. На него очень приятное впечатление произвел tygra.
Сейчас мне кажется, что ошибочно :)

2pkarklin
<Можно я немного пофлэймлю, а?>
Думаю, большая часть ответа, действительно, флейм :)
Но я готов ответить
-------------
<А для кого мелкомягкие придумали рабту с офлайн файлами, другие средства синхронизации файлов, Портфель, наконец. Не представляю, как бы я сопровождал свои проекты (за 1500 форм и модулей)с вашим подходом >
Подход сложился исторически. Он не абсолютен - у него есть и плюсы и минусы. Могу сказать только, что потенциально в наших проектах бесконечное число форм - реально, если развернуть цепочку "стандартно" - будет не меньше модулей, а так - каждый проект - 3-5 модуля. Кстати, и сопровождение облегчается на порядок. В конце концов, я согласен с предыдущим Вашим утверждением, что "каждый выбирает по себе" :).
-------------
<Вместо того, чтоб большую часть рутинной работы касаемой пользовательского интерфейса сделать в дизайнтайм вы все это делаете в коде. Это идиотизм. >
Оценка - категоричная и, как следствие, непродуманная :).
Вместо того, чтобы соображать в каждом проекте где какую форму вызывать, подключать кучу базовых форм и т.п. - кинул один компонент и забот не знаешь. Да, на создание такого компонента тратишь времени больше, чем в designe-time. Реально - часа три работы. Но при многократном использовании время экономится сторицей. К тому же, "базовый исходник" прописывается и выверяется тщательно - дополнительная гарантия, что не забыл проставить какое-то свойство, правильно положил компонент на форму /например, строго по горизонтали/ и т.п. "Лучше сперва потратить два часа, потом сорок раз сэкономить по пятнадцать минут и избавиться от кучи дополнительных забот...
------------
<Да потому-что в голове не умещается где вы подсмотрели или кто вас научил так вести проекты>
Подход исторически возник года три назад.
До этого использовались предлагаемые Вами решения - приходилось тратить много сил на включение в каждый новый проект кучи "базовых форм", оформленных отдельными модулями. Автор подхода, к сожалению, не я /наш руководитель - именно про него я уже говорил :)/.
------------
<Ваше счасть, что не я у вас РМ, поразогнал бы к чертям собачим>
Я не знаком с Вашими проектами - скажу, что скорость разроботки и эффективность сопровождения "нашего подхода" меня в свое время впечатлило. Сначала я тоже решил, что наш руководитель сошел с ума, но на практике с удивлением увидел рост эффективности даже не в разы, а на порядок. Думаю, такой скачок Вы вряд ли может обеспечить :)
------------
<На tygra балоны не кати, а внимательно слушай, че он говорит. >
Не беспокойтесь, не обижаю я Вашего tigr-у. Да, думаю, ему мое мнение
"по-бараьану". Но то, что он ошибся /возможно, невнимательно прочитав вопрос/ - факт. А мне не понравилось его хамство. Можно было разговаривать нормально.
Например, с Вами мы общаемся нормально. Вы считаете неоправданным такие приемы, но не хамите, а пытаетесь понять точку зрения собеседника, что приятно.
---------
P.S. Кстати, в ответе tygra я не увидел ничего кроме весьма недалекой иронии. Если Вы подскажете, что мне прочитать внимательно /надеюсь, я Вас убедил, что создавать формы, компоненты и использовать uses я умею :)/, я буду Вам признателен и принесу свои извинения и Вам и tigre :)

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