Interface aus DLL mit dynamischer Bindung - wann FreeLibrary aufrufen?

[DeddyH]

Das war die entscheidende Kleinigkeit, von der ich gesprochen hatte. Danke Dir herzlich :)

[Blup]

Für ein Plugin-DLL scheint es mir flexibel, wenn diese selbst die von ihr bereitgestellten Interfaces bei der Anwendung registriert.
Dazu wird dem Plugin ein Interface zum Anwendungskern übergeben, bei dem beliebige Interfaces registriert und abgefragt werden können.

Beispiel könnte ein Exportdateiformat sein. Davon kann es mehrere geben, für den Anwendungsfall ist es egal welche davon in der Anwendung oder in einem Plugin realisiert sind.
Der Dateiexport fragt alle registrierten Formate beim Anwendungskern ab, bietet diese dem Anwender an und erzeugt die Datei im gewählten Format.
Sollte dieses Dateiformat die Namen von Artikelgruppen benötigen, kann es dafür vom Anwendungskern ein Interface abfragen, das eine entsprechende Liste bereitstellt.
Das Dateiformat kann in der Plugin-Dll realisiert sein und die Schnittstelle mit den Artikelgruppen in der Anwendung.

[Sir Rufo]

Also in ungefähr so

Delphi-Quellcode:

IPlugin = interface
  ['{GUID}']
end;

IPluginHost = interface
  ['{GUID}']
  procedure RegisterPlugin( const Aplugin : IPlugin );
end;

Jede Plugin-DLL bietet eine Methode zum Abrufen an:

Delphi-Quellcode:

procedure QueryPlugin( const Host : IPluginHost ); stdcall;
begin
  Host.RegisterPlugin( TFooPlugin.Create );
  Host.RegisterPlugin( TBarPlugin.Create );
  ...
end;

[DeddyH]

Danke für die Denkarbeit, aber in diese Richtung geht es nicht (es gibt nur ein Interface, und jede DLL gibt exakt dieses zurück). Ich muss zugeben, dass der Begriff PlugIn in der Problemstellung etwas irreführend war.

[Sir Rufo]

Zitat:

Zitat von DeddyH (Beitrag 1313455)

Danke für die Denkarbeit, aber in diese Richtung geht es nicht (es gibt nur ein Interface, und jede DLL gibt exakt dieses zurück). Ich muss zugeben, dass der Begriff PlugIn in der Problemstellung etwas irreführend war.

Das macht doch nichts, wenn jede DLL nur ein Interface zurückgibt.

Die Dll liefert zunächst nur ein Interface vom Typ

Delphi-Quellcode:

IPlugin

zurück, welches aber auch das benötigte

Delphi-Quellcode:

INeededInterface

unterstützt:

Delphi-Quellcode:

TFoo = class( TInterfacedObject, IPlugin, INeededInterface )
end;

Die Anwendung selber nimmt sich dann alle Plugins, die das gewünschte Interface unterstützen.

Dadurch wird es wurscht, welche Interfaces eine DLL zur Verfügung stellt, man hat genau einen Einsprungspunkt und darüber kann ich jede Funktionalität aus der DLL herauslutschen. Auch die, die ich mir heute noch nicht vorstellen kann.

Und einen wirklichen Overhead habe ich dadurch auch nicht. ;)