Пакет с собственными формами (наследование + IDE)

← →
alextorin © (2006-11-12 10:48) [0]

Не раз затрагивалась в том или ином виде тема наследования форм.... Но мой вопрос о наследовании формы из bpl с определенными условиями - форма не обычный компонент, но вот что нужно...

Создал проект с подгрузкой пакетов в рантайме. Собственно сам проект только и предназначен для инициализации и запуска приложения, а также подгрузки и выгрузки нужных пакетов (bpl) со своими формами и функционалом...
Так вот идея в следующем:
1) один пакет (bpl) с определенными формами (все наследники от TForm) - это базовые формы - смысл этого пакета - содержать в себе эти "базовые" формы, от которых потом будут наследоваться формы в других пакетах (проектах);
2) все остальные отдельно взятые bpl - цельная и законченная задача (например, справочник материалов) и формы в них наследуются от "базовых" форм;
3) наследование любой из "базовых" форм в новом пакете интересует на этапе дизайна, при этом сама "базовая" форма не должна добавляться в этот новый пакет;
4) пакет с "базовыми" формами при создании новых пакетов (проектов) не должен располагать *.pas файлами.

Если кто знает как добиться выполнения п. 3 и 4 подскажите пожалуйста.
Если идея не совсем ясна - жду вопросов.

← →
Юрий Зотов © (2006-11-12 11:16) [1]

Если базовые формы не имеют новых свойств или событий, то достаточно просто поместить их в репозиторий (правый клик по форме).

Если имеют, то: http://delphimaster.net/view/5-1154350531/

← →
имя (2006-11-12 14:20) [2]

Удалено модератором

← →
имя (2006-11-12 16:03) [3]

Удалено модератором

← →
имя (2006-11-12 16:14) [4]

Удалено модератором

← →
имя (2006-11-12 16:18) [5]

Удалено модератором

← →
имя (2006-11-12 16:20) [6]

Удалено модератором

← →
имя (2006-11-12 16:30) [7]

Удалено модератором

← →
имя (2006-11-12 16:36) [8]

Удалено модератором

← →
имя (2006-11-13 00:47) [9]

Удалено модератором

← →
имя (2006-11-13 00:55) [10]

Удалено модератором

← →
имя (2006-11-13 01:41) [11]

Удалено модератором

← →
имя (2006-11-13 01:57) [12]

Удалено модератором

← →
имя (2006-11-13 11:41) [13]

Удалено модератором

← →
alextorin © (2006-11-13 12:15) [14]

Теперь по теме:
1. Меня не интересует как сделать паблишед свойства видимыми в инспекторе... У меня для некоторых "базовых" форм такая задача вообще не стоит... И как компоненты сделать видимыми в наследниках - этот вопрос тоже я не затрагивал...
2. Из Вашего скриншота видно, что рядом стоит предок и наследник - допустим... Вопрос - предок тоже добавляется в Project1 при создании новой формы, наследованной от него... Если нет, то жду ваших коментариев...
Если да, то:
1) попробуйте убрать предка из проекта;
2) сохраните и закройте проект;
3) откройте проект - разве Делфи ничего не хочет при этом и нормально открывает наследника в дизайнере (и dfm тоже)...
Вот это и есть то, что не получается у меня...

← →
Юрий Зотов © (2006-11-14 01:07) [15]

> 2. Из Вашего скриншота видно, что рядом стоит предок и наследник -
> допустим...

LOL. Я их в фотошопе нарисовал? а Delphi и не запускал даже?
"Вы не в церкви, Вас не обманут".
(с) Ося Бендер.

> Вопрос - предок тоже добавляется в Project1 при создании новой
> формы, наследованной от него...

Написан базовый класс формы (в который и введено новое свойство), сидит этот класс в пакете. Еще написан эксперт IDE, позволяющий создавать наследников этого класса. Первый наследник - это тот, который на экране слева, он сидит в репозитории и несет на себе компоненты. А тот, который на экране справа - это наследник наследника. Обе эти рабочие формы добавлены в проект (иначе где же они будут компилиться?), а вот сама базовая форма в проект не входит, она так и сидит в своем пакете.

Но у Вас задача проще, и вот почему:
> 1. Меня не интересует как сделать паблишед свойства видимыми в
> инспекторе

Если так, то вообще никаких проблем.

> 3) наследование любой из "базовых" форм в новом пакете интересует
> на этапе дизайна, при этом сама "базовая" форма не должна добавляться
> в этот новый пакет;

Во-первых, совершенно очевидно, что для этого базовый пакет должен быть:
а). инсталлирован в IDE;
б). прописан в requires рабочего пакета.

Это строго обязательно. А далее - есть два способа создания наследника.

Первый способ простой, но не очень удобный - базовые формы помещаются в репозиторий (например, на отдельную страницу). Тогда формы в рабочем пакете наследуются от базовых обычным способом, но IDE (по крайней мере, семерка) добавит базовые формы в рабочий пакет и не даcт их оттуда удалить. Нужно удалить их ручками, прямо в тексте секции contains в dpk, а потом сохранить и переоткрыть пакет. После этого все уже станет OK.

Второй способ намного сложнее, но зато удобнее для юзера - к базовому пакету добавляется еще один design-time пакет, в котором сидит эксперт IDE (должен реализовывать интерфейсы IOTAWIzard, IOTARepositoryWizard,
IOTARepositoryWizard60, IOTAFormWizard) - вот он-то все и рулит. Тогда базовые формы помещать в репозиторий не потребуется, не будут они появляться и в рабочем пакете. Как написать такой эксперт - это песня долгая и отдельная (и, честно говоря, проще его написать, чем объяснить, как это делается).

> 4) пакет с "базовыми" формами при создании новых пакетов (проектов)
> не должен располагать *.pas файлами.

Для создания рабочего пакета достаточно инсталлировать базовый пакет в IDE. То есть, надо иметь bpl, dcp и dcu базового пакета и всех его юнитов.

PS
> это немного не мой уровень - прошел года 2 назад...
Не знаю, кто, когда и куда прошел, но для дизайнтаймщика эта задачка - практически детская (если не писать эксперт). А уж сообразить про инсталляцию базового пакета, секцию required рабочих пакетов и репозиторий... это любой component writer просто обязан был сделать. А также component writer обязан знать, что нужно для работы с пакетом без его исходников. Так что подобные "апломбированные" заявления... ну, Вы поняли, да? Ни к чему они. Уровень - он и так виден, без слов.

PPS
И теперь, если проанализировать решение с репозиторием, то неожиданно выяснится... что ответ был дан в первом же посте. Том самом, который Вы обозвали флудом.
:о)

← →
имя (2006-11-14 01:42) [16]

Удалено модератором

← →
alextorin © (2006-11-14 01:44) [17]

Хочу все же уточнить суть проблемы...
Если провести тест подобным образом, то можно наткнуться на мои грабли...
Сам тест (это просто тест поэтому за примитивизм прошу прощения):

1. Создал run-time пакет pTest с единственной формой TestForm и добавил ее в репозиторий. Откомпилил - все ок...
2. Создал dessign-time пакет pTestDessign, включил в него пакет pTest. Добавил модуль mTest - в нем я зарегистрировал форму как RegisterCustomModule(TTestForm, TCustomModule).
откомпилил, проинсталил - все ок.
3. Создал новый run-time пакет pPac1, включил в него пакет pTest, добавил форму из репозитория (наследовал от TestForm) TestForm1 - при этом в проект пакета добавилась и форма предок TestForm, но при компиляции она удалилась, т.к. ранее был добавлен requires pTest - вобщем все ок - как и задумано в Делфи... откомпилил, сохранил, закрыл - все ок...
4. Удалил (убрал в др. место) mTestForm.pas (это pas формы TestForm) - остались только dfm и dcu.
5. Открываю проект пакета pPac1 - все ок. TestForm1 открылась без ошибок... Закрыл проект.
6. А вот теперь заковыка - я пытаюсь в новый пакет или в открытый старый добавить из репозитория форму (наследовать от TestForm) - получается ошибка: Unable to find both a form (D:\Project\Temp\mTestForm.dfm) and source source file (D:\Project\Temp\mTestForm.pas). - это из-за того, что я скрыл mTestForm.pas

Подскажите как эту ошибку обойти.
Изначально мой вопрос был обширным - свел все к конкретной задаче...

← →
alextorin © (2006-11-14 01:45) [18]

Вобщем свел все к п.4 изначально поставленного вопроса.
п.3 пока не важен
- он важен только если я добавляю форму (наследую от "базовой") в проект без подгрузки пакетов в рантайме.

← →
имя (2006-11-14 03:09) [19]

Удалено модератором

← →
имя (2006-11-14 03:59) [20]

Удалено модератором

← →
atruhin © (2006-11-14 06:00) [21]

> базовые формы помещаются в репозиторий (например, на отдельную
> страницу).

Тоже заинтересовался вашей дискуссией, как поместить форму на отдельную страницу?
Намекните.

← →
Юрий Зотов © (2006-11-14 07:39) [22]

F1: Object Repository dialog box.

Add Page button
To add a new blank page, click the Add Page button. The Add Page dialog box appears. Type the name of the page you want to add and click OK.

← →
имя (2006-11-14 20:41) [23]

Удалено модератором

← →
имя (2006-11-14 23:32) [24]

Удалено модератором

← →
имя (2006-11-15 00:46) [25]

Удалено модератором

← →
имя (2006-11-15 00:56) [26]

Удалено модератором

← →
имя (2006-11-15 00:58) [27]

Удалено модератором

← →
имя (2006-11-15 01:00) [28]

Удалено модератором

← →
имя (2006-11-15 10:40) [29]

Удалено модератором

← →
имя (2006-11-18 17:45) [30]

Удалено модератором

← →
имя (2006-11-20 08:14) [31]

Удалено модератором

Так как модератор многое вырезал (было много лишнего сказано) - повторюсь немного...
Может я и не правильно понял Юрия, но понял я примерно следующее...
В рантайм пакет запихиваем базовую форму... В дизайн пакете регистрируем ее через RegisterCustomModule... Затем создаем от нее наследника ,помещаем на него компоненты (если таковые необходимы) и пихаем его в репозиторий, а затем наследуем от последнего "рабочие" формы... При этом и "промежуточный наследник" и наследники от него будут добавляться в новый проект...
Если я не правильно понял - поправте меня...
А если все так, то:
Мне не нужно создавать "промежуточного наследника" и пихать в него компоненты - компоненты затрагиваются в реализации функционала в "базовой" форме - потому в ней и должны находиться... Тем более, что "промежуточный наследник" в самом проекте - тот еще вариант...
Уважаемый Юрий - если я не правильно понял, что-то из Вашего совета - прошу меня поправить, а если правильно, то такой вариант мне не подходит - спасибо.

> alextorin © (20.11.06 23:37) [32]

> В рантайм пакет запихиваем базовую форму... В дизайн пакете
> регистрируем ее через RegisterCustomModule...

Если в нее добавлены свойства/события. Если нет - регистрация не требуется. Но в любом случае пакет с базовой формой должен быть загружен в IDE - либо сам по себе (как пакет двойного назначения), либо через другой design-time пакет.

> Затем создаем от нее наследника ,помещаем на него компоненты (если
> таковые необходимы) и пихаем его в репозиторий, а затем наследуем от
> последнего "рабочие" формы...

Так было сделано в моем варианте (почему - скажу ниже), но он не единственный. Компоненты могут лежать и не на промежуточном наследнике, а непосредственно на базовой форме (если я правильно понял, это и есть то, что Вам нужно, поэтому подробнее - тоже ниже).

> При этом и "промежуточный наследник" и наследники от него будут
> добавляться в новый проект...

Если промежуточный наследник не лежит в пакете, то ведь должен он где-то компилироваться? Должен. Поэтому он должен быть (и будет) добавлен в проект (как оно и было в моем варианте). Но если он лежит в пакете, то его машинный код уже и так имеется, поэтому в проекте он не нужен. И в репозитории он тоже не будет нужен - но тогда, очевидно, для его создания в design-time придется писать эксперт.

Теперь - почему в качестве иллюстрации я привел вариант с промежуточным наследником? Просто потому, что он был под рукой, когда-то давно уже написанный. И для иллюстрации совместной работы RegisterCustomModule и репозитория этот пример вполне подходит.

Теперь о главном - как бы я решал Вашу задачу.

1. В run-time пакете создал базовую форму со всеми нужными компонентами и кодом.

2. Создал design-time пакет, в который входят RegisterCustomModule (если требуется) и (самое главное!) эксперт IDE, позволяющий создавать в новом проекте потомка этой базовой формы.

Вот с этой самой задачей (написание такого эксперта) года три назад я и бился насмерть, аж пару месяцев - потому что не жил этот зксперт вместе с RegisterCustomModule. Либо-либо, а вместе - никак, на унаследованной форме исчезали компоненты. Более того - не получалось даже и само наследование: несмотря на то, что эксперт создавал DFM где черным по белому было прописано inherited, среда упрямо его игнорировала и писала собственный DFM, без компонентов и с object вместо inherited (естественно, поэтому и поднималась пустая форма).

Как уже говорилось, тогда проблема эта так и не была решена - и даже корифеи BDN во главе с Эриком Берри ничего реального посоветовать не смогли. По всей видимости, это был баг (или фича?) самой IDE, потому что позднее (в семерке с UpdatePack 2) эту задачу решить все же удалось (и даже без особых усилий, потому что тот же самый когда-то написанный эксперт вдруг нормально заработал).

Отсюда выводы:
а). нужна версия не ниже семерки с UpdatePack 2.
б). действуем по вышеизложенным п.п. 1 и 2.

> не жил этот зксперт вместе
> с RegisterCustomModule. Либо-либо, а вместе - никак, на
> унаследованной форме исчезали компоненты. Более того - не
> получалось даже и само наследование: несмотря на то, что
> эксперт создавал DFM где черным по белому было прописано
> inherited, среда упрямо его игнорировала и писала собственный
> DFM, без компонентов и с object вместо inherited (естественно,
> поэтому и поднималась пустая форма).

Кстати, Юрий, а эта проблема наблюдалась именно с формой? Потому как у меня на Delphi6 в принципе нормально работает эксперт, создающий модуль с потомком хм... потомка TDataModule (каламбурчик получился). При этом базовый класс содержал новые свойства и таки да, для него я вызывал RegisterCustomModule

С формой - было, с DataModule - не знаю, не пробовал.

А базовый DataModule нес компоненты?

Нет, компонент на нем не было. Только несколько новых свойств и методов. Впрочем, будет время - попробую. Действительно интересно

Пакет с собственными формами (наследование + IDE) Найти похожие ветки