Динамическое создание компонентов из класса экспортирумый из dll : Cannot Assign TFont to TFont + Access Violation на выходе

[WhiskasTM]

С Новым Годом!

BPL не предлагать, ладно?

Суть, из dll грузится плагин который оформлен ввиде класса отдельным юнитом, он делает кнопку на форме главного приложения.

Интерфейс плагина(типа абстрактного класса)

unit uPluginInterface;

interface

type
  IPlugin = class
    procedure MakeButton;virtual;abstract;
  end;

implementation
end.

Допустим плагин, ввиде класса:

unit uWindows20;

interface

uses Vcl.Forms, Vcl.StdCtrls, uPluginInterface;

type
  TWindows20 = class(IPlugin)
  private
    Form:TForm;
    Btn:TButton;
  public
    procedure MakeButton;override;
    constructor Create(pForm:TForm);
  end;

implementation

constructor TWindows20.Create(pForm: TForm);
begin
 Form:=pForm;
end;

procedure TWindows20.MakeButton;
begin
 Btn:=TButton.Create(Form);
 with Btn do
  begin
  ParentFont:=false;
  Parent:=Form;
  Caption:='Launch Windows 20';
  end;
end;

end.

DLL с экспортом этого класса:

library Plugin;

uses
  Vcl.Forms,
  System.SysUtils,
  System.Classes,
  uPluginInterface in 'uPluginInterface.pas',
  uWindows20 in 'uWindows20.pas';

{$R *.res}

function __load(pForm:TForm):IPlugin;stdcall;
begin
  Result:=TWindows20.Create(pForm);
end;

exports
__load;

begin
end.

Приложение грузит плагин:

uses uPluginInterface;

.......

TLoad = function (pForm:TForm):IPlugin;stdcall;

var
  Form1: TForm1;
  Plugins:array of IPlugin;
  Load:TLoad;

implementation

{$R *.dfm}

procedure TForm1.FormCreate(Sender: TObject);
var
H:THandle;
begin
SetLength(Plugins,1);
H:=LoadLibrary(PWideChar('Plugin.dll'));
Load:=GetProcAddress(H,PWideChar('__load'));
Plugins[0]:=Load(Form1);
Plugins[0].MakeButton;
end;

Все работает (при условии, что при создании кнопки ParentFont стоит False, иначе будет Cannot Assign TFont to TFont).
Работает и ладно, но при закрытии формы выдается ошибка access violation. В call stack-е последним идет :00482b72 ListRemove+$A

Как починить?

EDIT:
Починил. Нужно чтоб сам плагин кнопку свою освобождал

TWindows20 = class
....
destructor Destroy;override;

....

implementation
....

destructor TWindows20.Destroy;
begin
Btn.Free;
end;

Плюс освобождать плагины в главном приложении:

procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
var
i:integer;
begin
for i := 0 to High(Plugins) do Plugins[i].Free;
end;

Так всегда, мучался/учился дня 3, а стоило только сделать тему... ещё одна лишняя тема.

[spamer]

ТС, посмотри вот сюда - урл, думаю будет полезно...

[WhiskasTM]

О, да, видел когда-то, но мало че тогда понимал и забыл. Здорово, придется чай наварить.

Кстати, тупую кнопку-то я сделал на главной форме, а вот держать события она не может, т.е. банально не выполняет их(события также в классе декларируются). Но зато когда сделать сначала панель, а затем на панели эту кнопку то все ОК. Че за грабли блин везде...

[Кольша]

мне кажется или при создании кнопки надо еще передать Tfont основного приложения...

[WhiskasTM]

Все это бесполезно. А если работать ещё и со сторонними компонентами, то там такие ошибки выходят, что гугл выдает "нет результатов".

Раз уж приложение хочет быть расширяемым, то пусть само оно и предоставляет методы затем экспортирует их.

function SA_AddPanel(
const pOwner,pParent:TWinControl;
const pAlign:TAlign;
const pAnchors:TAnchors;
const pLeft,pTop,pWidth,pHeight:integer;
const bBorderOuter:TFrameStyleEx=fsNone;
const pTag:integer=0):TRzPanel;safecall; external 'Application.exe';

У меня таких десятка два теерь и вообще никаких проблем. А че, шикарно же =)

[evg_m]

точную причину назвать не смогу, но копать надо в сторону ShareMem.
DLL и EXE как абсолютно НЕЗАВИСИМЫЕ (на уровне Delphi не Windows) имеют ОТДЕЛЬНЫЕ менеджеры памяти (одинаковые но работающие независимо друг от друга). И каждый свой список типов объектов.
При работе с DLL безопасно(не имеет проблем) передавать можно только общесистемные типы(integer, point, Pchar,...) там где нечего делать менеджеру памяти. (не классы, и даже не string). Нandle передать можно.

создали удалили объекты =>сработал менеджер памяти DLL(выделили память) => выгрузили DLL => сработал менеджер памяти DLL(очистка) => использовали объект DLL =>AV
создали удалили объекты =>сработал менеджер памяти DLL(выделили память) => оставили DLL => сработал менеджер памяти DLL(очистка) => использовали объект DLL =>AV

shareMem данную проблему частично снимает.
Не зря ПЕРВОЙ же строчкой ВАС об этом предупреждают.

library Project1;

{ Important note about DLL memory management: ShareMem must be the
  first unit in your library's USES clause AND your project's (select
  Project-View Source) USES clause if your DLL exports any procedures or
  functions that pass strings as parameters or function results. This
  applies to all strings passed to and from your DLL--even those that
  are nested in records and classes. ShareMem is the interface unit to
  the BORLNDMM.DLL shared memory manager, which must be deployed along
  with your DLL. To avoid using BORLNDMM.DLL, pass string information
  using PChar or ShortString parameters. }

Такое верно для D7, что с новыми версиями не знаю.

D7 Help Writing dynamically loadable libraries

Note

If your application includes VisualCLX components, you must use packages instead of DLLs or shared objects. Only packages can manage the startup and shutdown of the Qt shared libraries.

A package is a specially compiled library used by applications, the IDE, or both. Packages allow you to rearrange where code resides without affecting the source code. This is sometimes referred to as application partitioning.