Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Подземелье Магов
  
 

Фильтр по датам

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  18:52[Войти] | [Зарегистрироваться]

Обсуждение материала
Подгружаемые модули (plugins) в Delphi
Полный текст материала


Цитата или краткий комментарий:

«... Когда я впервые столкнулся с задачей организации подгружаемых в RunTime модулей (plugins) для Delphi-программ, ответ нашелся достаточно быстро. Как это иногда бывает в подобных ситуациях, я не особо задумался о том, как подобную задачу решают другие разрабточики. .....
Метод, предлагаемый мною, основан на использовании механизма, которым пользуется сама Delphi IDE - пакеты (packages).
...»


Важно:
  • Страница предназначена для обсуждения материала, его содержания, полезности, соответствия действительности и так далее. Смысл не в разборке, а в приближении к истине :о) и пользе для всех.
  • Любые другие сообщения или вопросы, а так же личные эмоции в адрес авторов и полемика, не относящаяся к теме обсуждаемого материала, будут удаляться без предупреждения авторов, дабы не мешать жителям нормально общаться.
  • При голосовании учитывайте уровень, на который расчитан материал. "Интересность и полезность" имеет смысл оценивать относительно того, кому именно предназначался материал.
  • Размер одного сообщений не должен превышать 5К. Если Вам нужно сказать больше, сделайте это за два раза. Или, что в данной ситуации правильнее, напишите свою статью.
Всегда легче осудить сделанное, нежели сделать самому. Поэтому, пожалуйста, соблюдайте правила Королевства и уважайте друг друга.



Добавить свое мнение.

Результаты голосования
Оценка содержания

  Содержит полезные и(или) интересные сведения
[1]2392%
 
  Ничего особенно нового и интересного
[2]28%
 
  Написано неверно (обязательно укажите почему)
[3]00%
 
Всего проголосовали: 25

Оценка стиля изложения

  Все понятно, материал читается легко
[1]1768%
 
  Есть неясности в изложении
[2]832%
 
  Непонятно написано, трудно читается
[3]00%
 
Всего проголосовали: 25




Смотрите также материалы по темам:
[TObject] [TApplication] [Использование пакетов (BPL)] [Модель плагинов]

Комментарии жителей
Отслеживать это обсуждение

Всего сообщений: 27

22-01-2009 07:26
Что мешает регистрировать класс подключаемого из модуля библиотеки как
Как минимум то, что вызвав RegisterClass из бибилиотеки вы его никогда не найдёте вызвав FindClass из основного приложения или другой библиотеки. Так же могут неправильно работать статические методы передаваемых между модулями (в терминах виндов, то есть EXE и DLL) классов и обращения к глобальным переменным (RegisterClass как раз поэтому и не заработает).
В принципе все эти проблемы решаются компиляцией DLL с пакетами, но предпочтительнее использовать сразу пакет, а не DLL.
 DRON


22-01-2009 06:29
Вопрос.
цитата
"...Неприятность заключается в том, что эти модули будут находиться в памяти дважды и тот TParser, о котором знает основная программа не совпадает с тем, который знает plugin...."
Что мешает регистрировать класс подключаемого из модуля библиотеки как
RegisterClass(...);
а при окончании использования
UnRegisterClass(...);
А в runtime находить его по уникальному имени FindClass() для создания объекта?
 sams


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 сократится - пусть на немного, но там и компонентов немного.
 sams


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:19
1. 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 ( я же его и
разрабатываю).

Хороший материал, может пригодится в будущем.

Спасибо ;)))


Добавьте свое cообщение

Вашe имя:  [Войти]
Ваш адрес (e-mail):На Королевстве все адреса защищаются от спам-роботов
контрольный вопрос:
"Мы с тобой одной крови — ты и я!". Чьи это заветные слова?
в качестве ответа на вопрос или загадку следует давать только одно слово в именительном падеже и именно в такой форме, как оно используется в оригинале.
Надоело отвечать на странные вопросы? Зарегистрируйтесь на сайте.

Оценка содержания
 
Содержит полезные и(или) интересные сведения
 
Ничего особенно нового и интересного
 
Написано неверно (обязательно укажите почему)


Оценка стиля изложения
 
Все понятно, материал читается легко
 
Есть неясности в изложении
 
Непонятно написано, трудно читается

Текст:
Жирный шрифт  Наклонный шрифт  Подчеркнутый шрифт  Выравнивание по центру  Список  Заголовок  Разделительная линия  Код  Маленький шрифт  Крупный шрифт  Цитирование блока текста  Строчное цитирование
  • вопрос Круглого стола № XXX

  • вопрос № YYY в тесте № XXX Рыцарской Квинтаны

  • сообщение № YYY в теме № XXX Базарной площади
  • обсуждение темы № YYY Базарной площади
  •  
     Правила оформления сообщений на Королевстве
      
    Время на сайте: GMT минус 5 часов

    Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
    Функция может не работать в некоторых версиях броузеров.

    Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
    Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

     
    © При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

    Яндекс цитирования