Подскажите как правильно работать с библиотеками BPL

← →
Павел Калугин © (2012-11-13 14:45) [0]

Что надо:
Есть приложение содержащее довольно большое количество списочных форм и еще болщее количество "редакторов"
Соответственно есть желание разнести формы по библиотекам, чтобы при модификации отдельно взятого окна не надо было пересобирать всю балалайку
Как хочу реализовать
Формы по тематике группируются в библиотеки. Например все формы касающиеся отображения/редактирования данных лиц закладываем в partners.bpl
Приложению сообщаем для какого "условного типа" какую форму поднимать в виде "Наименование библиотеки", "Наименование класса формы""
Соответственно при выборе пункта меню "Список лиц" по данным вида Partners.BPL, TFmPartnersList надо подгрузить библиотеку и открыть соответствующую форму.
Теперь вопросы чайника
Как правильно провешивать в такой организации ссылки на такие базовые вещи как модуль данных, конект к БД общие наборыы данных и т.д.?Как поместить в библиотеку несколько форм?
Как при этом обходится с наследованием? Держать библиотеку с базовыми классами форм и ссылатся на неё при создании библиотек с наследниками?
Как по наименованию библиотеки и класса открыть форму?

← →
Игорь Шевченко © (2012-11-13 18:45) [1]

http://delphikingdom.com/asp/viewitem.asp?catalogid=274
http://delphikingdom.com/asp/viewitem.asp?catalogid=468

← →
Павел Калугин © (2012-11-13 18:48) [2]

Спасибо!

← →
Павел Калугин © (2012-11-14 00:25) [3]

Почитал. Непонимание таки осталось

Создал проект библиотеки package
В библиотеке модуль
unit fDm; interface uses System.SysUtils, System.Classes, Data.DBXMSSQL, Data.Win.ADODB, Data.DB, Data.SqlExpr; type TdmMain = class(TDataModule) adcMain: TADOConnection; private { Private declarations } public Procedure ConnectDb; Procedure DisConnectDb; { Public declarations } end; var dmMain: TdmMain; implementation {%CLASSGROUP "System.Classes.TPersistent"} {$R *.dfm} { TdmMain } procedure TdmMain.ConnectDb; begin adcMain.Connected:=True; end; procedure TdmMain.DisConnectDb; begin adcMain.Connected:=False; end; initialization if not Assigned(GetClass("TdmMain")) then RegisterClass(TdmMain); finalization if Assigned(GetClass("TdmMain")) then UnRegisterClass(TdmMain); end.

В приложении вызов

procedure TfmMain.FormCreate(Sender: TObject); var LibClass: TDataModule; LibHandle: HMODULE; begin LibPath :=ExtractFilePath(Application.ExeName)+"Lib\"; // Showmessage( LibPath); LibHandle:=LoadPackage (LibPath+"BaseClass.bpl"); LibClass:=TDataModule(GetClass("TdmMain")); if LibClass= nil then raise Exception.create("Ошибка при создании компонента."#10 + "Класс TdmMain не зарегистрирован"); LibClass.Create(self); end;

на LibClass.Create(self) получаю AV ПОчему?

← →
Юрий Зотов © (2012-11-14 00:56) [4]

Переменная LibClass должна быть ссылкой на класс, а не ссылкой на экземпляр класса.

var
LibClass: TDataModuleClass; // В uses добавить CtlPanel
MyDataModule: TDataModule
...
LibClass:=TDataModuleClass(GetClass("TdmMain"));
MyDataModule := LibClass.Create(self);

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

Паш, а че это ты вдруг в кодинг врезался? Ты же аналитик, вроде как?

← →
Павел Калугин © (2012-11-14 01:38) [6]

Ошибку понял.
Дядь Юр, ну одно другому не мешает. Надо же на кошках идейки опробовать иногда :)

Теперь остался непонятным второй вопрос.
Что мне делать если нужна форма, которую надо унаследовать от формы лежащей в другой библиотеке.
В BaseClass я помещаю класс формы
TModalDataList = class(TfModalDialogForm) PFilter: TPanel; BitBtn3: TBitBtn; SpList: TADOStoredProc; dgList: TDBGrid; dsList: TDataSource; pmList: TPopupMenu; private { Private declarations } public { Public declarations } procedure IsShowButtons(IsShow : boolean); end;

В другой библиотеке мне надо создать от этой формы наследника,
Как мне к библиотеке пускай Partners подключать вот эту библиотеку с базовыми классами? чтоб получить, к примеру, вот такое
type TfmPartnersList = class(TModalDataList) est1: TMenuItem; procedure est1Click(Sender: TObject); private { Private declarations } public { Public declarations } end;

← →
Германн © (2012-11-14 02:25) [7]

> а че это ты вдруг в кодинг врезался?

Жисть заставляет, имхо.
Чем сейчас могут "старики" превзойти молодых? Только тем, что старики могут в короткие сроки освоить несколько "смежных" областей.

← →
Павел Калугин © (2012-11-14 09:55) [8]

Герман, мне б про это наследование понять....
А почему, зачем - задачки иногда просто-так решать надо. Для удовольствия. Ну и эта. Чтоб потом можно было менторским тоном произнести: ну я же говорил, вот тут в 17-й строке накосячил, так что перестаешь изобретать и пишешь по ТЗ. Иногда, увы, так надо...

← →
cobalt © (2012-11-14 11:33) [9]

> Павел Калугин © (14.11.12 01:38) [6]
надо новый класс поместить тоже в bpl, указав "компилировать с использованием bpl класса-предка"

← →
Юрий Зотов © (2012-11-14 12:54) [10]

> Германн © (14.11.12 02:25) [7]
> Чем сейчас могут "старики" превзойти молодых? Только тем,
> что старики могут в короткие сроки освоить несколько "смежных"
> областей.

Ничего себе "только". Неслабое такое...
:o)

← →
Павел Калугин © (2012-11-14 15:04) [11]

> надо новый класс поместить тоже в bpl, указав "компилировать
> с использованием bpl класса-предка"

То есть, если я чо-то поменял в библиотеке класса-предка надо пересобрать библиотеки с потомками?

← →
cobalt © (2012-11-14 15:06) [12]

> То есть, если я чо-то поменял в библиотеке класса-предка
> надо пересобрать библиотеки с потомками?
Скорее всего.

← →
Павел Калугин © (2012-11-14 15:18) [13]

> Скорее всего.

Да, такой самолет не полетит.... Хотя... А может и полетит. Смотреть надо
Еще раз куда надо стучать молотком чтобы при разработке нового пакета можно было создать наследника от формы лежащей в другом пакете? Если можно по шагам по кнопкам....

← →
Юрий Зотов © (2012-11-14 23:09) [14]

> Павел Калугин © (14.11.12 15:18) [13]
> Еще раз куда надо стучать молотком чтобы при разработке
> нового пакета можно было создать наследника от формы лежащей
> в другом пакете? Если можно по шагам по кнопкам....

Никуда не надо стучать, все само сделается. Вот смотри.

Класс TForm лежит в пакете VCLxx.bpl. Мы делаем свой BPL, а в нем - наследника TForm. Компилячим наш BPL c runtime пакетами, включая VCLxx.bpl - и все работает. Хотя ничего специального мы не делали.

То же самое и в случае, когда предок лежит не в VCLxx.bpl, а в нашем пакете. Надо просто скомпилячить пакет потомка с runtime пакетом предка.

А если говорить глобально - попробуй посмотреть в сторону интерфейсов и COM. Вот гляди.

Есть MS Word, который, как известно, является COM-сервером. Мы пишем приложение, которое работает с ним, как COM-клиент. Потом обновляем версию Word"а на совершенно другую - а наша программа продолжает работать с ним без проблем и без всякой перекомпиляции.

Происходит это потому, что новый Word поддерживает тот же самый интерфейс, что и старый (возможно, еще и расширяя его), а нашей программе безразлично, кто и как снабжает ее этим интерфейсом. Ей только надо знать, как до него достучаться и какие методы он содержит. Причем программа в этом случае может быть написана не только на Delphi.

Подумай на эту тему - не то ли самое ты ищешь? Word, конечно, взят для примера, вместо него у тебя будет свой COM-сервер.

← →
Германн © (2012-11-15 02:49) [15]

> Павел Калугин © (14.11.12 09:55) [8]
>
> Герман, мне б про это наследование понять....

← →
cobalt © (2012-11-15 10:52) [16]

Сдается мне, джентельмены, что нас троллят...

← →
Павел Калугин © (2012-11-15 11:51) [17]

> Компилячим наш BPL c runtime пакетами

В упор не могу найти где это у пакета типа package
У приложения - есть такой фо=лаг и перечень проектов а у библиотеки не вижу (ХЕ2 стоит)

> Сдается мне, джентельмены, что нас троллят...

Сээр, как ни странно все это вполне сурьёзные вопросы. Стандартные дурацкие моменты, возникающие когда идейка есть надо бы код уже писать а как - не знаю/не понимаю

В том же POwer Builder - Как просто. Указал окно, в коде прописал из какой библиотеки на него DW пришлепать и аля-улю, гони гусей.

← →
Павел Калугин © (2012-11-16 00:45) [18]

Совсем умумукался. Гдет тут этот флах про рантайм ставить?
Для проекта он тут есть. А для package где?
http://mmp.flat-design.ru/picwindow.php?cat=8&pic=1432

← →
Германн © (2012-11-16 00:59) [19]

> Павел Калугин © (16.11.12 00:45) [18]
>
> Совсем умумукался. Гдет тут этот флах про рантайм ставить?
>

Может быть Юра имел в виду секцию Requires в пакете?

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

Там пакет стоит.
При этом класс из него от которого вроде как наследник должен быть в ошибке как неопознанный. И при создании новой формы в inherrit выбор не предлагается
Хотя... Странно все это.

Создал пустую форму. Указал в USES форму предка из подцепленной в Requires библиотеки
Указал что TfmPartnersLst = class(TModalDataList)
Пакет скомпилен.
Но визуально на форме ничего не поменялось.

УРЯЯЯ волшебное слово inherited в ДФМ-ке и вроде как заработало! ща проверять бум!

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

Завтра.. Пока работает но через анус...
Приходится создавать форму а потом руками писать окуда она наследуется. Но работает!

Но как то непонятно
При удалении компонента на предке приходится библиотеку с потомком пересобирать.
ПРи добавлении обработчика событий тоже самое.

А вот при изменении обработчика или при добавлении визуального компонента - работает без "пересборки" предка.

Ниче не понимаю опять

> Ниче не понимаю опять

Завтра, значит завтра.
Но ты уж давай завтра реальный код приводи.

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

"При разработке пакетов нельзя менять (для сохранения совместимости с прошлыми программами):

1. Добавлять виртуальные методы в классах в интерфейсной части юнитов перед имеющимися виртуальными методами. Добавлять обычные методы можно в любое место.
2. Добавлять динамические методы (в том числе обработчики оконных сообщений) в классах в интерфейсной части юнитов перед имеющимися динамическими методами.
3. Добавлять поля в классы в интерфейсной части юнитов.
4. Удалять любые методы в классах в интерфейсной части юнитов (переименование считается за удаление)
5. Удалять любые поля в классах в интерфейсной части юнитов (переименование считается за удаление)
6. Изменять типы параметров в любых методах классов или функциях в интерфейсной части юнитов, добавлять и удалять параметры.
7. Изменять типы и имена глобальных переменных в интерфейсной части юнитов.
8. Записи (record), интерфейсы (interface) и глобальные типы (type) считаются классами со всеми вытекающими.
9. Константы (const) считаются глобальными переменными со всеми вытекающими.
10. Менять секции initialization и finalization юнитов, входящих в пакет.
11. Переносить поля (и методы) из области видимости published из/в любые другие области. Между областями private/protected/public поля можно переносить, если не меняется их порядок следования.
12. Удалять юниты из пакета.

Все остальное можно изменять без потери совместимости с предыдущими откомпилированными версиями приложений/DLL/BPL, в том числе, добавлять новые юниты в пакет.
"

Игорь, спасибо! Распечатаю дома и приколочу на стену. По крайней мере пока с этими паветами не наиграюсь.

Павел Калугин © (16.11.12 15:13) [27]

Есть еще добавление - нельзя удалять секции initialization/finalization. Нельзя делать ничего, что меняет таблицу эскпорта, размеры экземпляров типов, и т.п.

Подскажите как правильно работать с библиотеками BPL Найти похожие ветки