Текущий архив: 2003.02.06;
Скачать: CL | DM;
Вниз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]Забыл уже где видел - давно это было. Даже забыл в чем проявляется.
← →
REA (2003-01-24 16:23) [16]Вот проверил:
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)
← →
REA (2003-01-25 12:32) [17]2Игорь Шевченко:
Ау. Есть возражения, замечания, грязные ругательства?
← →
Mystic (2003-01-25 12:49) [18]У меня этот код работает (на форме появляется новая кнопка).
Что я сделал не так?
Я бы реализовывал все через интерфейсы, наподобие OpenToolsAPI. Имхо удобнее.
← →
REA (2003-01-25 12:56) [19]Хм. Может статически BPL подключил?
Лениво COM прецеплять и непонятно что это даст. А если интерфейсы без COM то тем более непонятно что даст.
← →
asmith (2003-01-25 15:36) [20]COM дает возможность использовать одну вещь, которая очень полезна при мспользовании подгружаемых модулей. Имя ей - COM Component Categories. В двух словах это означает, что можно группировать подгружаемые модули в некие категории компонентов и есть возможность в любой момент узнать, какие модули принадлежат той или иной группе. Простой пример-одна группа модулей расширяет функциональность меню "View" моей программы, вторая-меню "Edit". Часть модулей регистрирую в одной категории, часть в другой. При загрузке программы запрашиваю сначала первую категорию, встраиваю в первое меню, затем вторую... Написал новый модуль, зарегистрировал в нужной категории и все - встроится автоматом, где требуется.
ЗЫ. Реализуется эта кухня на удивление просто.
← →
Игорь Шевченко (2003-01-27 11:46) [21]REA © (25.01.03 12:32)
Есть. EXEшник должен быть скомпилирован с использованием пакета vclxx.bpl
← →
REA (2003-01-27 11:51) [22]2asmith: У меня в принципе с 96 года plugin manger по такому принципу сделан, но только еще хитрее - он грузит группы плагинов и в качестве параметра получает указатель на метакласс враппера плагина. Получается на выходе группа классов со всеми функциями код которых в DLL.
2Игорь Шевченко: Tnanx, забыл я дурак, щас попробую.
Страницы: 1 вся ветка
Текущий архив: 2003.02.06;
Скачать: CL | DM;
Память: 0.49 MB
Время: 0.01 c