DLL или BPL

← →
REA © (2003-01-23 10:57) [0]

Думаю как лучше сделать плугины. Я всегда делал DLL и вот решаю - надо ли мне использовать packages вместо этого. Если кто делал - поскажите ошутимые преимущества. Больше всего конечно мне не нравится, что у них (DLL и EXE) разные RTTI и классы не проверить на тип и не передать из одного в другое - при попытках присвоения визуальным элементам несовпадение типов.

← →
Calm © (2003-01-23 11:05) [1]

Пакеты дадут суммарно меньший объем файлов и меньше загрузят память при запуске.
Но использовать их могут только приложения Delphi и CBuilder.
Выбирай, что важнее.

← →
Игорь Шевченко © (2003-01-23 11:07) [2]

http://www.delphikingdom.com/mastering/plugins.htm

IMHO, BPL лучше, так как исключается проблема с дублированием VMT и глобальных переменных VCL, например, Application.
Кроме того, суммарный объем EXE + plugins DLL обычно больше, чем
EXE + plugins BPL + system BPLs

← →
REA © (2003-01-23 11:14) [3]

Если использовать DLL с включенными пакетами, то размер тот же. Приложение ориентировано на Delphi и не планируется расширение на другие языки.

Application конечно неудобная вешь, но не принципиальная.
А что там насчет дублирования VMT?

← →
Игорь Шевченко © (2003-01-23 11:19) [4]

REA © (23.01.03 11:14)

А вместо DLL сразу BPL использовать ?
А статью прочитать ?

О дублировании - класс TForm в DLL и TForm в EXE это два разных класса, друг с другом не совместимые, по крайней мере по IS и AS.
Обычно это проявляется на классе TFont.
Кроме того, дублируется переменная Application, отсюда проблемы с созданием в DLL MDIChild форм.

← →
REA © (2003-01-23 11:25) [5]

Статью читал несколько раз (и сегодня в том числе).

>О дублировании - класс TForm в DLL и TForm в EXE это два разных >класса, друг с другом не совместимые, по крайней мере по IS и AS.

Код то тот же (он в BPL), а RTTI разные. Это и неудобно. Потому и спрашиваю - даст ли использование BPL какой-то шаг в напралении объединения RTTI - сдается мне, что нет.

>Кроме того, дублируется переменная Application, отсюда проблемы с созданием в DLL MDIChild форм.

MDI мне в данном случае не нужен, но работает в других проектах и с MDI почти без проблем.

← →
REA © (2003-01-23 11:28) [6]

Вопрос в догонку: будет ли для классов динамических BPL работать streaming system (RegisterClass/Save resource/Load resource) при вызове загрузки из основной программы?

← →
Игорь Шевченко © (2003-01-23 14:35) [7]

>Код то тот же (он в BPL), а RTTI разные

Если с пакетами, то одинаковые.

Почему бы не почитать ?

http://www.delphikingdom.com/mastering/plugins.htm

RegisterClass будет, остальное - вопрос непонятен.

← →
REA © (2003-01-24 13:32) [8]

Да читал я эту статью 5 раз. О чем речь то? - разница может быть только за счет объявления асбсолютно абстрактных классов, но посколько я классы (кроме тех что определены в стандартных VCL) в DLL не использую, то DLL может быть даже меньше по размеру. Примерно 50к на плугин - меня это устраивает.

А вопрос про то что если зарегистрировать класс в DLL, а загрузить ресурс в основной программе, то при конструкции класса должна быть корректная ссылка на метакласс. Наверно это будет работать. Хотелось бы уйти от разных RTTI - чтобы из BPL была возможность расширять интерфейс.

← →
REA © (2003-01-24 15:11) [9]

Что то я запутался - если глобальные переменные общие (а это кстати как достигается?), то и FindClass должен возвращать одинаковые классы, поскольку использует глобальную переменную RegGroups для поиска. Почему тогда возникает несоответствие типов? Или я что-то не так делаю? А если в DLL передать указатель на FindClass, то можно создать класс из контекста программы по его имени?

← →
Игорь Шевченко © (2003-01-24 15:13) [10]

> если глобальные переменные общие (а это кстати как достигается?),
>

Помещением их в один пакет.

Остальные вопросы я не понял.

← →
REA © (2003-01-24 15:21) [11]

По порядку: при попытке добавить кнопку из DLL (или BPL) на панель основной программы вылетает "TFont is not TFont", что очевидно, поскольку для создания и Assign используются разные таблицы. Вопрос как их (RTTI) объединить либо создать класс в DLL (BPL) c помощью метакласса основной программы (ссылающийся на RTTI Exe), что бы не возникало конфликтов. Передачей указателя на FindClass из Exe в DLL не отделаться?

← →
Игорь Шевченко © (2003-01-24 15:26) [12]

REA © (24.01.03 15:21)

> при попытке добавить кнопку из DLL (или BPL) на панель основной
> программы вылетает "TFont is not TFont",

Из BPL этого быть не может.
hint: EXEшник тоже должен быть скомпилирован с использованием run-time пакетов.

← →
REA © (2003-01-24 15:31) [13]

Я проверю конечно, но кажется я уже пробовал - DLL и BPL в этом смысле не отличаются. А RTL я всегда подключаю - DLL без них глючат, хотя и с ними глючат, когда идет каскадирование DLL-DLL-DLL, но это документированный баг Микрософт.

← →
oomneeq © (2003-01-24 15:44) [14]

>REA © (24.01.03 15:31)
>.. когда идет каскадирование DLL-DLL-DLL, но это документированный баг Микрософт.

Что за документированный баг?
Мне актуально, как раз каскадирование.
Есть ссылка, где про него прочесть?

← →
REA © (2003-01-24 15:55) [15]

Забыл уже где видел - давно это было. Даже забыл в чем проявляется.

Вот проверил:
Exe:

TTestProc = Procedure(Parent: TWinControl);

procedure TForm1.Button1Click(Sender: TObject);
begin
TTestProc(GetProcAddress(LoadPackage(ExtractFilePath(Application.ExeName)+"test.bpl"),
"test"))(Self);
end;

BPL:
Procedure test(aParent: TWinControl);
Begin
With TButton.Create(Application) Do
Begin
Left := 10;
Top := 10;
Parent := aParent;
End;
End;

Та же ошибка (cannot assign TFont to TFont)

2Игорь Шевченко:
Ау. Есть возражения, замечания, грязные ругательства?

У меня этот код работает (на форме появляется новая кнопка).
Что я сделал не так?

Я бы реализовывал все через интерфейсы, наподобие OpenToolsAPI. Имхо удобнее.

Хм. Может статически BPL подключил?
Лениво COM прецеплять и непонятно что это даст. А если интерфейсы без COM то тем более непонятно что даст.

← →
asmith (2003-01-25 15:36) [20]

COM дает возможность использовать одну вещь, которая очень полезна при мспользовании подгружаемых модулей. Имя ей - COM Component Categories. В двух словах это означает, что можно группировать подгружаемые модули в некие категории компонентов и есть возможность в любой момент узнать, какие модули принадлежат той или иной группе. Простой пример-одна группа модулей расширяет функциональность меню "View" моей программы, вторая-меню "Edit". Часть модулей регистрирую в одной категории, часть в другой. При загрузке программы запрашиваю сначала первую категорию, встраиваю в первое меню, затем вторую... Написал новый модуль, зарегистрировал в нужной категории и все - встроится автоматом, где требуется.
ЗЫ. Реализуется эта кухня на удивление просто.

2asmith: У меня в принципе с 96 года plugin manger по такому принципу сделан, но только еще хитрее - он грузит группы плагинов и в качестве параметра получает указатель на метакласс враппера плагина. Получается на выходе группа классов со всеми функциями код которых в DLL.

2Игорь Шевченко: Tnanx, забыл я дурак, щас попробую.

DLL или BPL Найти похожие ветки