Уважаемые господа!
Помогите, пожалуйста советом.
В 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 :)