![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Подскажите как правильно работать с библиотеками BPL
Павел Калугин © (2012-11-13 14:45:00)Что надо:
Есть приложение содержащее довольно большое количество списочных форм и еще болщее количество "редакторов"
Соответственно есть желание разнести формы по библиотекам, чтобы при модификации отдельно взятого окна не надо было пересобирать всю балалайку
Как хочу реализовать
Формы по тематике группируются в библиотеки. Например все формы касающиеся отображения/редактирования данных лиц закладываем в partners.bpl
Приложению сообщаем для какого "условного типа" какую форму поднимать в виде "Наименование библиотеки", "Наименование класса формы''
Соответственно при выборе пункта меню "Список лиц" по данным вида Partners.BPL, TFmPartnersList надо подгрузить библиотеку и открыть соответствующую форму.
Теперь вопросы чайника
Как правильно провешивать в такой организации ссылки на такие базовые вещи как модуль данных, конект к БД общие наборыы данных и т.д.?Как поместить в библиотеку несколько форм?
Как при этом обходится с наследованием? Держать библиотеку с базовыми классами форм и ссылатся на неё при создании библиотек с наследниками?
Как по наименованию библиотеки и класса открыть форму?
Игорь Шевченко (2012-11-16 15:28:00) [1]Павел Калугин © (16.11.12 15:13) [27]
Есть еще добавление - нельзя удалять секции initialization/finalization. Нельзя делать ничего, что меняет таблицу эскпорта, размеры экземпляров типов, и т.п.
Павел Калугин (2012-11-16 15:13:00) [2]Игорь, спасибо! Распечатаю дома и приколочу на стену. По крайней мере пока с этими паветами не наиграюсь.
Игорь Шевченко (2012-11-16 12:48:00) [3]
> Но как то непонятно
> При удалении компонента на предке приходится библиотеку
> с потомком пересобирать.
> ПРи добавлении обработчика событий тоже самое.
"При разработке пакетов нельзя менять (для сохранения совместимости с прошлыми программами):
1. Добавлять виртуальные методы в классах в интерфейсной части юнитов перед имеющимися виртуальными методами. Добавлять обычные методы можно в любое место.
2. Добавлять динамические методы (в том числе обработчики оконных сообщений) в классах в интерфейсной части юнитов перед имеющимися динамическими методами.
3. Добавлять поля в классы в интерфейсной части юнитов.
4. Удалять любые методы в классах в интерфейсной части юнитов (переименование считается за удаление)
5. Удалять любые поля в классах в интерфейсной части юнитов (переименование считается за удаление)
6. Изменять типы параметров в любых методах классов или функциях в интерфейсной части юнитов, добавлять и удалять параметры.
7. Изменять типы и имена глобальных переменных в интерфейсной части юнитов.
8. Записи (record), интерфейсы (interface) и глобальные типы (type) считаются классами со всеми вытекающими.
9. Константы (const) считаются глобальными переменными со всеми вытекающими.
10. Менять секции initialization и finalization юнитов, входящих в пакет.
11. Переносить поля (и методы) из области видимости published из/в любые другие области. Между областями private/protected/public поля можно переносить, если не меняется их порядок следования.
12. Удалять юниты из пакета.
Все остальное можно изменять без потери совместимости с предыдущими откомпилированными версиями приложений/DLL/BPL, в том числе, добавлять новые юниты в пакет.
"
Германн (2012-11-16 02:47:00) [4]
> Ниче не понимаю опять
Завтра, значит завтра.
Но ты уж давай завтра реальный код приводи.
Павел Калугин (2012-11-16 02:38:00) [5]Завтра.. Пока работает но через анус...
Приходится создавать форму а потом руками писать окуда она наследуется. Но работает!
Но как то непонятно
При удалении компонента на предке приходится библиотеку с потомком пересобирать.
ПРи добавлении обработчика событий тоже самое.
А вот при изменении обработчика или при добавлении визуального компонента - работает без "пересборки" предка.
Ниче не понимаю опять
Германн (2012-11-16 02:12:00) [6]Паш, пришла пора давать реальный код, который мы сможем проверить.
Иначе наши телепаторы могут сломаться из-за банального перегрева. :)
Павел Калугин (2012-11-16 02:11:00) [7]УРЯЯЯ волшебное слово inherited в ДФМ-ке и вроде как заработало! ща проверять бум!
Павел Калугин (2012-11-16 02:02:00) [8]Там пакет стоит.
При этом класс из него от которого вроде как наследник должен быть в ошибке как неопознанный. И при создании новой формы в inherrit выбор не предлагается
Хотя... Странно все это.
Создал пустую форму. Указал в USES форму предка из подцепленной в Requires библиотеки
Указал что TfmPartnersLst = class(TModalDataList)
Пакет скомпилен.
Но визуально на форме ничего не поменялось.
Германн (2012-11-16 01:01:00) [9]Поскольку "та самая галка" в обычном проекте имеет совсем другой смысл.
Германн (2012-11-16 00:59:00) [10]
> Павел Калугин © (16.11.12 00:45) [18]
>
> Совсем умумукался. Гдет тут этот флах про рантайм ставить?
>
Может быть Юра имел в виду секцию Requires в пакете?
Павел Калугин (2012-11-16 00:45:00) [11]Совсем умумукался. Гдет тут этот флах про рантайм ставить?
Для проекта он тут есть. А для package где?
http://mmp.flat-design.ru/picwindow.php?cat=8&pic=1432
Павел Калугин (2012-11-15 11:51:00) [12]
> Компилячим наш BPL c runtime пакетами
В упор не могу найти где это у пакета типа package
У приложения - есть такой фо=лаг и перечень проектов а у библиотеки не вижу (ХЕ2 стоит)
> Сдается мне, джентельмены, что нас троллят...
Сээр, как ни странно все это вполне сурьёзные вопросы. Стандартные дурацкие моменты, возникающие когда идейка есть надо бы код уже писать а как - не знаю/не понимаю
В том же POwer Builder - Как просто. Указал окно, в коде прописал из какой библиотеки на него DW пришлепать и аля-улю, гони гусей.
cobalt (2012-11-15 10:52:00) [13]Сдается мне, джентельмены, что нас троллят...
Германн (2012-11-15 02:49:00) [14]
> Павел Калугин © (14.11.12 09:55) [8]
>
> Герман, мне б про это наследование понять....
Юрий Зотов (2012-11-14 23:09:00) [15]
> Павел Калугин © (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-14 15:18:00) [16]
> Скорее всего.
Да, такой самолет не полетит.... Хотя... А может и полетит. Смотреть надо
Еще раз куда надо стучать молотком чтобы при разработке нового пакета можно было создать наследника от формы лежащей в другом пакете? Если можно по шагам по кнопкам....
cobalt (2012-11-14 15:06:00) [17]> То есть, если я чо-то поменял в библиотеке класса-предка
> надо пересобрать библиотеки с потомками?
Скорее всего.
Павел Калугин (2012-11-14 15:04:00) [18]
> надо новый класс поместить тоже в bpl, указав "компилировать
> с использованием bpl класса-предка"
То есть, если я чо-то поменял в библиотеке класса-предка надо пересобрать библиотеки с потомками?
Юрий Зотов (2012-11-14 12:54:00) [19]
> Германн © (14.11.12 02:25) [7]
> Чем сейчас могут "старики" превзойти молодых? Только тем,
> что старики могут в короткие сроки освоить несколько "смежных"
> областей.
Ничего себе "только". Неслабое такое...
:o)
cobalt (2012-11-14 11:33:00) [20]> Павел Калугин © (14.11.12 01:38) [6]
надо новый класс поместить тоже в bpl, указав "компилировать с использованием bpl класса-предка"