Flexibles Pluginsystem: Diskussion

[gsh]

Nein das Flexible Pluginsystem von mir beruht NICHT auf dem Tutorial von sakura (ich kannte des zu dem zeitpunkt noch nicht mal)

und du hast mehr von sakura reinkopiert kommt mir vor denn in meinem TUT ist keine einzige Klasse und der Parameter ist auch ein ganz ein anderer

[LH_Freak]

Zitat:

Zitat von gsh

Nein das Flexible Pluginsystem von mir beruht NICHT auf dem Tutorial von sakura (ich kannte des zu dem zeitpunkt noch nicht mal)

und du hast mehr von sakura reinkopiert kommt mir vor denn in meinem TUT ist keine einzige Klasse und der Parameter ist auch ein ganz ein anderer

das war mir schon bewusst keine angst...ich hab ja auch gesagt, dass ich die beiden gemischt habe...auf jedemfall hatte ich das vor zu schreiben oO falls das nicht dasteht...und dein "Tut" (weiß nicht, ich empfand es mehr als Denkansporn statt einer anleitung) hat mich eher auf die idee gebracht das so zu machen, da das 1. wie gesagt leicht ist und 2. wenn man darauf verzichtet, dass mit anderen Sprachen Plugins gemacht werden können, ist das auch garantiert einfacher zu handhaben als Interfaces usw.

Zitat:

Zitat von Kedariodakon

Für Plugins empfehlen sich Interfaces, gerade dann, wenn man auch Sprachenunabhängig arbeiten will (C, Delphi...)

Oder Packages, wenn man bei Delphi bleibt...

Denn mit sowas da

Delphi-Quellcode:

function LoadPlugin(Parent: THandle; var PlugIn: TPlugIn): Boolean; export; 
begin 
  try 
    PlugIn := TPlugIn01.Create(Parent); 
    Result := True; 
  except 
    Result := False; 
  end; 
end;

in dlls, kommt man sehr sehr schnell ans Limit der flexibilität...


Bye Christian

Das kommt immer drauf an wie man flexibilität definiert...nachdem ich das ganz einfach verwenden kann, ohne etwas an der Basisklasse zu ändern, finde ich das schon flexibel genug...ob ich etz da dann c oder sonstwas nehmen kann ist mir eher egal..;)

[Kedariodakon]

Problem dabei, die RTTI steht dir dabei nur bedingt zur Seite...
Was zu sehr vielen kleinen Problemen und AHA-Effekten führen wird.

Interfaces an sich sind gar nicht mal so schwer wie sie aussehen, zudem legen sie die Grundlage für schöne Erweiterungen, z.B. Com-Schnittstellen ec...

Bye Christian

[eLse-maestro]

Delphi-Quellcode:

var
  TempPluginRecord_PluginInit : TPluginRecord_PluginInit;
  PluginMain : procedure(Befehl : PChar; Parameter : Pointer);
begin
  {Plugin laden und PluginMain procedure zuweisen}
  TempPluginRecord_PluginInit.PluginSend := PluginSend; //PluginSend?
  TempPluginRecord_PluginInit.NochEinPChar := 'blabla';
  PluginMain('PluginInit', @TempPluginRecord_PluginInit);
end;

Hey Leute, kann mir jemand diesen teil erklären? mit "PluginSend;"?
1.klappt das bei mir nicht, ist ja auch nicht verwunderlich da ich das nicht deklariert habe,
und 2. ich kopiere nicht gerne source wo ich nicht alles verstehe..

[Chaosente]

ich hab da mal ne frage. oben wurde gasagt es empfiehlt sich interfaces zu verwenden. aber warum soll man dies tun, ich mein was hat das für nen vorteil oder warum stößt man dabei an die grenzen der flexibilität?

[thabaker]

Meiner Erfahrung nach gibt es zwei Probleme bei der Plugin/DLL-Geschichte:

* Strings
* Objekte und Klassen

Strings und alle nicht Basistypen wie integer, char, pointer (damit auch pchar) [was ist mit variants?] verursachen in DLLs Probleme. Hängt mit dem Speichermanager zusammen, kann jeder nachlesen, steht da wenn man eine neue DLL erstellt. Lösung hier ein anderer Speichermanager.

Bei Objekten und Klassen ist das ganze schon schwieriger zu lösen. Delphi macht es mit den Laufzeit Packages. Der Kern des Problems liegt darin, dass Delphi wissen muss dass ein "TObject" aus der Anwendung auch ein "TObject" aus der DLL ist. Was ja nicht der Fall sein muss, wenn die beiden mit verschiedenen Versionen erstellt wurden. Also wirft das hier erst einmal eine Exception:

Delphi-Quellcode:

  // code in der Anwendung, ObjektAusDLL wurde zuvor von der DLL initialisiert
  // z.B. mit ObjektAusDLL := TFormDLL.create( nil); return ObjektAusDLL
  if not(ObjektAusDLL is TObject) then raise Exception.create('Nicht mit Anwendungs-RTL kompatibel');
  // z.B.
  ObjektAusDLL.Parent := self;

Das zieht sich durch die ganze Klassenhierarchie und macht sich immer wieder durch Laufzeitfehler bemerkbar.
Die Lösung hier sind Interfaces, so zwar konsequent so, dass die Anwendungs-RTTI und die DLL-RTTI nicht miteinander in Berührung kommen. Denn Interfaces nutzen GUID's, die Sprachunabhängig definiert sind und so beliebig funktioneren.

D.h. man hat am besten als Include oder "interface"-Unit

Delphi-Quellcode:

  // ['{3F2504E0-4F89-11D3-9A0C-0305E82C3301}'] ist die GUID für das interface
  // kopiert aus dem wikipedia Artikel zu "Globally Unique Identifier"
  IUnserInterface = interface ['{3F2504E0-4F89-11D3-9A0C-0305E82C3301}']

und bindet diese sowohl in die Anwendung als auch in die DLL ein. Das ist wichtig damit die GUID in beiden identisch sind.
damit ist eine Abfrage erfolgreich:

Delphi-Quellcode:

  dllInstanz := GetDLLInterface;
  if dllInstanz is IUnserInterface then ShowMessage( 'Alles ok');

Man abstrahiert demnach das Identifizieren von gleichen Typen auf eine compiler- und plattformunabhängige Art.

ACHTUNG: Damit ist es aber immer noch nicht möglich Steuerelemente die in der DLL erstellt werden in der Anwendung zu benutzen! Ein Panel aus der DLL wird nicht auf einer Anwendungsform korrekt funktionieren, da die interne Struktur auf oben genannte Probleme keine Rücksicht nimmt!

[seim]

Ok das ist zwar alles schön und gut aber.. wie kann man eine DLL zur Laufzeit laden und das noch mit flexiblem Dateinamen oO?

Nur mal so als Beispiel:

Delphi-Quellcode:

function IcmpCreateFile : THandle; stdcall; external 'icmp.dll';

Das steht im interface Bereich.. wie bekomme ich so ein "icmp.dll" dynamisch zugeordnet?

[mschaefer]

Mir stellt sich da die Frage wie ich so ein Plugin in die Menüstruktur / Befehlstruktur einfüge:

Das Plugin muß eine Anmelderoutine haben wo es in Listenform angibt welche Befehle es anbietet und welche Menuenamen diese Befehle haben.
Eine Andere Vairante ist das es selbst ein Panel anbietet wo die einzelnen Befehle als Ereignisse hinterlegt sind. Bei anmelden des Plugins wird dann der Parent auf ein Panel der Hauptanwendung gelegt...

Grüße // Martin

[gsh]

Zitat:

Zitat von seim

Ok das ist zwar alles schön und gut aber.. wie kann man eine DLL zur Laufzeit laden und das noch mit flexiblem Dateinamen oO?

Nur mal so als Beispiel:

Delphi-Quellcode:

function IcmpCreateFile : THandle; stdcall; external 'icmp.dll';

Das steht im interface Bereich.. wie bekomme ich so ein "icmp.dll" dynamisch zugeordnet?

Bitte benutze die Suchfuntion dll dynamisch laden

Zitat:

Zitat von mschaefer

Mir stellt sich da die Frage wie ich so ein Plugin in die Menüstruktur / Befehlstruktur einfüge:

Das Plugin muß eine Anmelderoutine haben wo es in Listenform angibt welche Befehle es anbietet und welche Menuenamen diese Befehle haben.
Eine Andere Vairante ist das es selbst ein Panel anbietet wo die einzelnen Befehle als Ereignisse hinterlegt sind. Bei anmelden des Plugins wird dann der Parent auf ein Panel der Hauptanwendung gelegt...

Grüße // Martin

da musst du dir selbst was überlegen aber so zur anregung:
1. Du könntest für Plugins einen befehl bereitstellen der das MenuItem erstellt und verschiedene erreignisse zurückgibt.

2. Oder was glaube ich einfacher ist das du das Parent Object auf Anfrage übergibst und sie dann selber sich eine menü struktur anlegen können.