 | | | | |
| Подгружаемые модули (plugins) в Delphi |
Полный текст материала
Цитата или краткий комментарий: «... Когда я впервые столкнулся с задачей организации подгружаемых в RunTime модулей (plugins) для Delphi-программ, ответ нашелся достаточно быстро. Как это иногда бывает в подобных ситуациях, я не особо задумался о том, как подобную задачу решают другие разрабточики. .....
Метод, предлагаемый мною, основан на использовании механизма, которым пользуется сама Delphi IDE - пакеты (packages).
...» |
Важно:- Страница предназначена для обсуждения материала, его содержания, полезности, соответствия действительности и так далее. Смысл не в разборке, а в приближении к истине :о) и пользе для всех.
- Любые другие сообщения или вопросы, а так же личные эмоции в адрес авторов и полемика, не относящаяся к теме обсуждаемого материала, будут удаляться без предупреждения авторов, дабы не мешать жителям нормально общаться.
- При голосовании учитывайте уровень, на который расчитан материал. "Интересность и полезность" имеет смысл оценивать относительно того, кому именно предназначался материал.
- Размер одного сообщений не должен превышать 5К. Если Вам нужно сказать больше, сделайте это за два раза. Или, что в данной ситуации правильнее, напишите свою статью.
Всегда легче осудить сделанное, нежели сделать самому. Поэтому, пожалуйста, соблюдайте правила Королевства и уважайте друг друга.
Добавить свое мнение.
| | | Содержит полезные и(или) интересные сведения | | [1] | 23 | 92% | | | | | Ничего особенно нового и интересного | | [2] | 2 | 8% | | | | | Написано неверно (обязательно укажите почему) | | [3] | 0 | 0% | |
Всего проголосовали: 25 | | | | Все понятно, материал читается легко | | [1] | 17 | 68% | | | | | Есть неясности в изложении | | [2] | 8 | 32% | | | | | Непонятно написано, трудно читается | | [3] | 0 | 0% | |
Всего проголосовали: 25 |
[TObject] [TApplication] [Использование пакетов (BPL)] [Модель плагинов]
Отслеживать это обсуждение 
Всего сообщений: 2722-01-2009 07:26Что мешает регистрировать класс подключаемого из модуля библиотеки как
Как минимум то, что вызвав RegisterClass из бибилиотеки вы его никогда не найдёте вызвав FindClass из основного приложения или другой библиотеки. Так же могут неправильно работать статические методы передаваемых между модулями (в терминах виндов, то есть EXE и DLL) классов и обращения к глобальным переменным (RegisterClass как раз поэтому и не заработает).
В принципе все эти проблемы решаются компиляцией DLL с пакетами, но предпочтительнее использовать сразу пакет, а не DLL. |
|
22-01-2009 06:29Вопрос.
цитата
"...Неприятность заключается в том, что эти модули будут находиться в памяти дважды и тот TParser, о котором знает основная программа не совпадает с тем, который знает plugin...."
Что мешает регистрировать класс подключаемого из модуля библиотеки как
RegisterClass(...);
а при окончании использования
UnRegisterClass(...);
А в runtime находить его по уникальному имени FindClass() для создания объекта? |
|
22-01-2009 06:12Развернул plugins.zip. По-моему, в разделе requires пакета HTMLPluginProject.dpk совсем не нужно requeres vcl50.dcp, который уже присутствует как requires в пакете PluginInterfaceProject.dpk. А PluginInterfaceProject.dpk в свою очередь подгружает его для HTMLPluginProject.dpk. Не это ли было одной из целей статьи автора?
Если убрать из requires - vcl50.dcp в HTMLPluginProject.dpk, то объём HTMLPluginProject.bpl сократится - пусть на немного, но там и компонентов немного. |
|
26-08-2008 01:56| Хорошоя статья, но в Delphi 2007 это не работает. Почему, не известно пока. |
|
17-02-2007 03:24
09-10-2006 07:43
09-10-2006 05:36Не могу скачать файл с примером.
Не могли бы закачать на какой-нибудь файл-обменник. |
|
08-10-2006 04:50Вопрос по по поводу "следите за своевременной перекомпиляцией plugin"ов, если изменился абстрактный класс".
Можно подробнее? - При изменении модуля с абстрактным классом (в список vars добавлена еще одна переменная), другие модули этих изменений не видят (хотя ctrl+click возвращает в нужный модуль), никакая перекомпиляция не помагает.. Что я упустил?
Правда помогло зменение имени модуля этого абстрактного класса, но тут родилась иная проблема: значение, присвоенное переменной абстрактного класса в плагине(в разделе initialize) не видно из основной программы!! При более детальном разборе выяснилось, что раздел initialize модуля абстрактного класса вызывается дважды....
Вобщем я уже полностью запутался в этом, в чем ошибка или неточность???? |
|
01-11-2004 21:27| Спасибо автору очень полезная информация |
|
11-06-2004 17:37| Ссылка на архив восстановлена в тексте статьи. |
|
09-06-2004 19:14А где в настоящее время найти архив с исходниками?
На страничке со статьей ссылки на него нет.. |
|
16-10-2003 07:56>>>ak
Молодец!
Вопрос к автору (если отзовется).
Основной экзешник собирать с опцией "use runtime package"?
Спасибо. |
|
10-12-2002 05:24Автор статьи!!! Отзовись!!!
Пробовал отправить тебе письмо, не получилось:
-iamhere-@mail.ru - User not found
|
|
21-11-2002 12:30те три пункта, которые перечислены в разделе "минусы" - вещи второстепенные. коронная же фраза проскакивает в конце статьи: "следите за своевременной перекомпиляцией plugin"ов, если изменился абстрактный класс". а еще надо все пересобирать, если вы накатили очередной update на delphi, не говоря уже о переходе на новую версию. то есть вы меняете и ехешник, и плагины, и пакеты везде, где стоит ваша программа. в чем кайф-то собственно? это не плагины по большому счету, а распиленный на куски ехешник.
фраза "возня с пакетами нередко бывает утомительна и чревата "непонятными ошибками" вплоть до зависания Delphi" - вообще без комментариев. |
|
27-08-2002 16:19| Автор, СУПЕР!!!!! Я Это уже две недели ищу - нигде нет, а тут, прямо во всей красе написано! Но снова-таки, остается вопрос с Delphi/Builder и другими языками... :( |
|
04-07-2002 08:38Здравствуйте! У меня такой вопрос насчет DLL и Plugin"ов. Я хочу написать что-то типа плагина к своей программке, и нужно из DLL создать в моём приложении какой-либо контрол и работать с ним из DLL.
Что-то у меня не получается! Я передаю в DLL Handle моего окна (или чего-то там, где нужно создать контрол), через CreateWindowEx(...) с переданным Handle моего окна в качестве параметра окна-владельца. Но так ничего не получается! Что мне делать?
Хочется что бы контрол мог быть любым, а не только стандартные кнопок, Edit"ы, ComboBox"ы,...
Также приложение не должно знать какие контролы будут создаваться и как с ними будут работать.
Заранее большое спасибо!
|
|
21-01-2002 10:38Этот адрес может оказаться полезным.
http://www.uil.net/
The UIL Plugin System home page
Два компонента обеспечивающие удобный способ использования ПЛУГИНОВ.
Приятных сновидений.
lazarof@mail.ru
|
|
07-11-2001 18:03Материал классный. Кому придется возюкаться с плагигами – рекомендую.
Две вещи могу точно подтвердить:
1. Головняка, в отличии с dll, с подгрузкой/выгрузкой, общим доступом к иерархической структуре данных и пр. минимум. Именно по этой причине я выбрал «этот путь».
2. В результате общий физический объем действительно меньше, чем это было бы с Dll (тоже не маловажно).
Минусы конечно есть везде и здесь не без этого. Затруднена отладка, а при сбоях, в лучшем случае приходится перегружать Дельфю. Ну и то, что в bpl всё лежит полуоткрыто, и всяким хулигана «легко» можно переопределить функциональность программы. :) Это я про защиту.
|
|
16-09-2001 20:31Сразу скажу - статья написана для более-менее посвященного в это дело. Я вот только по демке разобрался что к чему. А разобравшись довел дело IMHO до высокого уровня. У меня есть основная прога, которая только грузит модули и соединяется с БД(с SQL или IB), а эти модули уже что хотят, то и творят(добавляют свои пункты меню, ToolBar"ы, юзают главный StatusBar). Остается только грамотно писать плуги и рассылать юзерам.
Спасибо большое автору за статью, она стала для меня отправной точкой. |
|
13-09-2001 14:43| Очень интересный материал. На мой взгляд это отличный метод работы с плагинами. |
|
30-04-2001 01:51| Если почитать книги по delphi (например Д.Тейлора, Т.Миллера, Н.Елмановой), то можно обнаружить более элегантные решения затронутой проблемы использующие технологии OLE или (что проще) COM, или (еще проще) интерфейсы. Прекрасно работает. |
|
17-01-2001 08:28Очень интересная идея.
Плагины такого рода имеют одно важное достоинство, о котором было упомянуто вскользь - это полный взаимный доступ ко внутренним ресурсам между плагинами и основной программой, когда все объекты из плагинов создаются в едином адресном пространстве. В результате мы имеем гарантировано корректное взаимодействие, например между всеми компонентами VCL в разных плагинах. Таким образом можно элементарно подключать DBGreed из одной библиотеки к датасету из другой или затянуть форму из библиотеки в TabControl основной программы с гарантированной обработкой всего потока событий дочерней формой.
Конечно, это всё будет работать в пределах одной версии Делфи.
Я такие вещи и в обычных DLL реализовывал, но там хлопот - немеряное количество и главное, некоторые компоненты, особенно от третих производителей, ловят глюки на обработке событий. |
|
07-08-2000 10:11Довольно интересный материал.
Однако если заглянуть в исходники Delphi, то функция LoadPackage - это SafeLoadLibrary (загрузка DLL), проверка дублирования модулей и вызов Initialize (функции) из загруженной DLL (BPL).
Что может быть проще?
|
|
03-08-2000 11:43По моему мнению, лучше использовать DLL, один аргумент, который приводит автор против DLL, так это размер библиотеки. Но если посчитать, то нужно около 5-ти библиотек с формами, чтобы выйти на тот же размер, что имеет необходимый при использовании пакетов VCL50.BPL. Но и тогда имеется выход, это компиляция и библиотек и основного модуля используюя этот пакет, при этом опять же получаем выигрыш. И привязка к конкретному компилятору, на самом деле, это не такой уж и маленкий недостаток.
А вообще, спасибо за статью. Доволно хорошо получилось :-)) |
|
02-08-2000 20:00| Очень порадовало, что автор досканально прокопал все за и против! Хотя случаев где реально нужно использовать пакеты и не так много (восновном плагины выполняют некие математические или алгоритмические функции), но их потдержка зашита в компилатор, что оччеенньь упрощает работу с ними! Хотя что это я(?), автор про это всё сказал! |
|
02-08-2000 06:191. dll можно компилировать с пакетами run-time. Это значительно
их облегчает...
2. Изменения интерфейса базового класса в любом случае вызовет
необходимость перекомпиляции всех проектов (exe, dll и пакетов).
Особых плюсов у пакетов в этом случае нет. Единственный вид dll,
свободный от этого (при упомянутой аккуратности разработчика) - это
COM.
3. все, что делает пакет легко воспроизводится в нормальной dll с
использование функций работы с классами типа:
function FindClass(const ClassName: string): TPersistentClass;
function GetClass(const ClassName: string): TPersistentClass;
procedure RegisterClass(AClass: TPersistentClass);
procedure RegisterClassAlias(AClass: TPersistentClass; const Alias: string);
не вижу особых преимуществ в пакетах. За исключением одного. Это,
пожалуй, единственный способ корректно упихать дочернюю форму в dll.
но недостаток (самый противный) проблемы с далнейшей доработкой/обновлением + привязка к Delphi/Builder.
Таким образом, для обычного плугина лучше использовать COM.
И возни меньше, и проще, и , соответственно, меньше возможности
ошибится...
|
|
01-08-2000 18:59Интересное предложение.
Я сделал несколько по другому.
Поскольку основной вещью с которой оперирую plug-in в моем проэкте
это изображения (hBitmap из API, большего не надо), плюс математика
которая обрабатывает картику.
То сделано все было как описано тобой в классическом варианте.
Да, каждая dll получается 'не маленькой', но пересобрав их с пакетами
от VCL я получаю того чего добился ты.
Плюс возможность писать такие плагины на чем угодно (главное
совпадениназваний функций).
А генерация меню это не проблема, просто проходишся по всем dll в
нужной дирректории.
Благодаря TStringList есть возможность построить иерархию меню,
с подстановкой пунктов в нужном месте.
Plug-in это класня идея.
Благодаря ей я раделил работу в коллективе.
Трое пишут dll, я за всем соежу и фиксю exe ( я же его и
разрабатываю).
Хороший материал, может пригодится в будущем.
Спасибо ;))) |
|
|
|
