PlugIn-System

[Tossi65]

Hallo Leute,
ich weiss, das Thema ist schon vorhanden. Aber für mich eben neu und echt interessant.
Ich will meine Anwendung in Module(PlugIns) aufteilen. Das einlesen der Module in eine
Liste ist da nicht das Problem. Und da hänge ich fest. In einem Modul können mehrere Forms
sein, welche ich auch in eine Liste aufführen möchte. Nur wie. Wie komme ich bei Modul init.
an die dran?:shock:

Was macht eigentlich RegisterClass?? Komme ich damit weiter?:?:

In den Projekten habe ich etwas von PlugIn-System V3.x gelesen, aber leider mann man
es nicht mehr dowloaden. Hat das noch jemand??:?:

[Bummi]

Was meinst Du mit Modulen? Dynamisch geladene DLL's?

[hanspeter]

Lass die Finger von Delphi und Plugin. Du handelst dir nur Probleme und null Nutzen ein.
Das dll/bpl Konzept von Delphi ist so verkorkst, das ein enormer Aufwand notwendig ist, um ein System lauffähig zu halten.
Dank RegisterClass funktioniert das ohnehin nur, wenn man mit Laufzeit-BPL arbeitet.
Da zieht man sich aber eine BPL Hölle an Land, gegen die die alte Dll Hölle ein Kinderspiel ist.
Wen ein modulares System geplant ist, dann würde ich mir entweder in Delphi die Com-Technologie anschauen oder auf ein moderneres Programmiersystem wechseln.
Wenn Altlasten kein Hinderungsgrund darstellen, würde ich über NET nachdenken. Mit Prism ist man da nicht weit vom in die Jahre gekommenen Delphi - Sprachstandard weg.
Ich habe mal ein Programmsystem auf das kommerzielle Plugin-System Hydra von Remobjects umgestellt. Damit bin ich letztendlich so auf die Nase gefallen, dass ich jetzt wieder Riesen-Exe Files ausliefere.
Die funktionieren dafür aber stabil.

Gruß
Peter

[RWarnecke]

Zitat:

Zitat von hanspeter (Beitrag 1061096)

Lass die Finger von Delphi und Plugin. Du handelst dir nur Probleme und null Nutzen ein.
Das dll/bpl Konzept von Delphi ist so verkorkst, das ein enormer Aufwand notwendig ist, um ein System lauffähig zu halten.

Ich sehe das ganze etwas anders. Ich habe für mein Programm Code-Orakel ebenfalls ein PlugIn-System mit DLL's gemacht. Es funktioniert sehr gut und is dazu auch noch perfomant. Mit Interfaces kann ich ein recht gutes PlugIn-System aufbauen.

Da aber Tossi65 nicht gesagt hat, wie groß es ist und wie komplex es werden soll, finde ich sollten wir Ihm bei seinem Problem helfen.

@Tossi:
Willst Du mit den modularen Fenstern nur einzelne Config-Dialoge anzeigen oder sollen das ganze Programmteile sein ? Ein bisschen Code wäre ebenfalls nicht schlecht, damit wir sehen wie Du die DLL's lädst und wie Du die bisherigen Abfragen machst. Benuttzt Du Interfaces oder lädst Du die DLL's dynamich oder statisch ?

[Tossi]

Wow???:):-D

Hey, die Diskussion sieht besser aus als die letzten, danke!!!

Ich will ganze Programmteile so steuern. Z.B. eine Adressverwaltung oder Rechnungsverwaltung.
Ich habe so etwas schon einmal gesehen, aber das reicht mir nicht. Ich will es auch verstehen.

Beim Programmstart soll ein Loader alle gefundenen Module(Dll) in eine Liste sopeichern und die
in den Modulen enthaltenen Formulare in eine weitere Liste. So hatte ich es mir gedacht.

@RWarneke
Ich möchte die Programmteile dynamisch laden. Ist ein Modul nicht da, gibt es halt den Programmteil nicht.
So kann man eine Adressverwaltung immer weiterentwickeln bis zu einen WaWi!!!!


Und danke für Eure Unterstützung

Thx
Tossi

[Bernhard Geyer]

Wenn die Schnittstelle der DLL C-Kompatible ist dann hast du auch kein Probleme mit der "BPL-Hölle". Jedoch darfst du dann auch kein "lebenden" Objekte übertragen.

Machen wir seit jahren und bis darauf das die DLL's mitlerweile ziemlich groß sind läuft es auch ganz gut.

[shmia]

Plugins, die eine bestimmte Verarbeitung vornehmen und keine eigene Oberfläche (Formulare) haben funktionieren als ActiveX/COM-Plugin recht gut.
Beispiele:
* Bildmanipulation - das externe Plugin bekommt ein Bitmap und schickt ein verändertes Bitmap (Weichzeichner, ...) zurück.
* Import-Plugin - das Plugin bekommt eine Datei mit best. Format und liefert die Daten aufbereitet zurück

Was überhaupt nicht gut funktioniert sind Plugins die ihre eigenen Formulare mitbringen und als Teil der Anwendung agieren sollen.
Grund: die VCL gibt es dann mehrfach in der Hauptanwendung und im Plugin.
Die beiden Instanzen der VCL kennen sich gegenseitig nicht und das macht Probleme.

Plugins machen nur dann Sinn, wenn es von einer bestimmten Pluginart mehrere Varianten gibt.
Also mehrere Plugins für Bildmanipulation oder Datenimport.

[Luckie]

Eventuell wäre auch ein fertiges Plugin-Framework interessant.

[Bummi]

Ich pflege seit 10 Jahren eine von mir erstellte Anwendung bei der rund 15 Module als DLL nachgeladen werden können (die Kunden des Kunden sollen bekommen was sie bezahlen wollen). Da die Module allen beinhalten was normale Anwendungen auch beinhalten, sich auch im Hauptmenü integrieren, die DLL's mit der Hauptanwendung und untereinander kommunizieren müssen, mußte ich die Erstellung mit Laufzeitpackes wählen. Dies alles ist mit einem selbst erstellen DLL-Template relativ problemlos und und schnell zu implementieren.
Ich würde es heute trotzdem nicht mehr so machen und die Modularität anders umsetzten. Ich klebe mit der Anwendung bis zum Sankt Nimmerleinstag auf Delphi 7 fest, da niemand eine Umstellung aller Einzelmodule auf eine aktuelle Version bezahlen würde. Das heißt auch neue Plugins müssen mit der Uraltverion nachgerüstet werden.

[Tossi]

@Brummi
Ja so ähnlich hatte ich mir das auch gedacht. Die Sache mit den BPL's kenne ich auch. Aber gibt es denn alternativen??
Natürlich wäre es besser wenn die Packages in den Modulen mit drin wären, aber dadurch werden diese riesen gross.

Ohne die Module gäbe es eine Anwendung nur mit einer MainForm. Mehr nicht. Ist ein Adressmdul vorhanden, dann kann ich
eben Adressen verwalten. Natürlich findet die gesamte Be- und Verarbeitung in den Modulen statt, auch visuell(Forms)!!

Thx
Tossi

[RWarnecke]

Zitat:

Zitat von Tossi (Beitrag 1061134)

@RWarneke
Ich möchte die Programmteile dynamisch laden. Ist ein Modul nicht da, gibt es halt den Programmteil nicht.
So kann man eine Adressverwaltung immer weiterentwickeln bis zu einen WaWi!!!!

Dann schaue Dir mal Interfaces an. Damit solltest Du soetwas hinbekommen. Ich habe dazu dieses Tutorial von sakura benutzt und hatte bis jetzt noch keine Probleme. Ich muss allerdings sagen, dass ich den ersten und den zweiten Teil vermischt habe um mehr Flexibilität zu erreichen.

[shmia]

Vielleicht brauchen wir noch eine Begriffsklärung was ein Plugin überhaupt ist.

Ein Plugin erfüllt eine öffentliche Schnittstelle (bestimmtes Interface oder auch eine Reihe von DLL-Funktionen)
Diese Schnittstelle sollte so designt werden, dass sie sich während der Lebenszeit der Anwendung nicht mehr verändert.

Plugins können in (fast) jeder Programmiersprache erzeugt werden.
Die Hauptanwendung kann Plugins anhand bestimmter Kriterien (z.B. best. Verzeichnis oder Anhand der COM-Kategorie) erkennen und im Prinzip beliebig viele Plugin dynamisch laden.

Ein Anwendungsmodul (so will ich das mal nennen) ist dagegen ein Teilstück einer modularisierten Anwendung.
In .NET entspricht das einem Assembly.
Jedes Anwendungsmodul hat seine eigene Schnittstellen die nicht öffentlich sind.
Während die Anwendung wächst können sich auch die Schnittstellen zu den Anwendungsmodulen verändern.
Anwendungsmodule müssen in der gleichen Entwicklungsumgebung erzeugt werden wie die Hauptanwendung.
Anwendungsmodule haben zwei Vorteile:
* man kann dem Benutzer best. Anwendungsmodule vorenthalten
* bei Bugfixes muss evtl. nur das Anwendungsmodul upgedatet werden

Ansonsten gibt es nur Nachteile für Delphi Programme.

[Tossi]

@Shmia
Ok sorry wenn ich etwas vertauscht habe, aber ich meine letzteres eben Anwendungsmodul.

Genau wie Du es beschrieben hast sollte es bestenfalls laufen. Das Porgramm wächst eben über die Module, die der Kunde dazu kaufen kann. Aber eben die Modulariesierung und eben die Umsetzung in die Listen da hapert es!

Das einlesen der Module aus einem Verzeichnis heraus, kein Problem aber wie komm ich an die Formulare in den Modulen
und wie sprech ich diese dann an.

Thx
Tossi

[Tossi]

hey,
ich dachte mir die Module einfach wie eine Dll mit LoadLibrary laden und bei Erfolg den Zeiger und Name in eine StringList. Nu müsste man die beinhalteten Forms ebenfalls in eine Liste packen. Da hakt es bei mir momentan.


Thx
Tossi

[Bummi]

Für die Forms sind die DLL's zuständig, Du musst exports für die gewünschten Funktionalitäten schreiben.
Du kannst den DLL's ein Callback mitgeben, über den sie die Hauptanwendung mit Informationen für Menüeinträge versorgen kann oder ein von der Hauptanwendung erstelles und wieder hochgereichtes Menuitem mit Leben zu erfüllen.
Der ganze Informationsaustausch lebt von sinnvoll implementieren Callbackfunktionen und exports.

[hanspeter]

Beispiel
dll/bpl A enthält Fastreport
dll/bpl B enthält Fastreport
Fastreport registriert sich über Registerclass

Modul A kann problemlos verwendet werden.
Modul B kann problemlos verwendet werden.

Wird versucht eines der beiden Module nachzuladen, wenn das jeweils andere Modul bereits geladen ist, dann knallt es und die Anwendung stürzt ab.
Hier nützen mir auch Interfaces nicht.
Das Problem kann ich einzig über ein Com-Object lösen.
Ich selbst habe mir ein Pugin-System auf Basis von Exe-Dateien gebaut.
Das Hauptprogramm ruft über einen Taskcontroler eine EXE auf und versorgt diese über Aufrufparameter.
Die Exe selbst kann z.B. ein beliebiges Panel im Hauptprogramm als Parent haben.
Das Ganze kann sowohl wie Show oder Showmodal aufgerufen werden. Nach Beenden des der Plugin-Exe kann ein Returncode ausgewertet werden.

Beispiel:
Nach Klick auf einen Menüpunkt ein externes Programm modal starten, im Parent des aufrufenden Programmes anzeigen. Auf Beendigung warten und dann den Return-Code auswerten.

Delphi-Quellcode:

 Tools : TTaskControl;
 Tools        :=  Task.Init(Parent, nil,'AUTTOOLS.EXE',modal);
 res := AutPlugin.Task.Startmodal(Self,Tools,'Kunde=1234,Rechnung=456,Artikel=1/2/3');

Warum ich keine bpl/dll verwende:
Die Module müssen immer in der gleichen Umgebung wie die exe kompiliert sein.
In unsauberen Umgebungen wie sie ab D7 abwärts entstanden sind, (z.B. bpl in System32) gilt das für alle anderen Delphiprogramme auf dem Rechner auch.
Also ich liefere Programm A,B,...Z an den Kunden aus. Dazu die Laufzeitumgebung. Alles läuft wunderbar.
Jetzt nehme ich für Programm J eine Änderung an irgendeinem Laufzeitmodul vor. Fazit neben den Änderungen für Programm J muss ich A..Z neu kompilieren und mit
ausliefern.
Von einem kleinen Compilerwechselchen von z.B. D2009 auf D2010 habe ich da noch garnicht geredet.
Delphi und Net haben den gleichen geistigen Vater. Net ist aus den Erfahrungen mit der Delpi- Entwicklung entstanden und Assemblys entschärfen fast alle Probleme , die bei der Modularisierung mit veralterten Programmiersystemen entstanden sind.
Wer heute noch größere Programmsysteme und diese auch noch modular ohne Sachzwänge mit D32 anfängt ist selber dran schuld.
Unter Sachzwängen verstehe ich entweder riese Altlasten an Code oder ein fortgeschrittenes Alter, wo ein Umgewöhnen nicht mehr möglich oder sinnvoll ist.
Dazu kommt im Vergleich zu anderen IDE noch die seit Versionen bugige IDE von Delphi.
Dabei muss man sich nichtmal von EB/CG und Delphi verabschieden, mit Delphi Prism steht eine um Generationen bessere Delphi-Version zur Verfügung.
Wenn ich nach Italien in den Urlaub fahre und habe einen Mercedes und einen Trabi-Oldtimer in der Garage stehen, dann nehme ich auch den Mercedes und nicht den Oldtimer.
Obwohl unter Abenteuergesichtspunkten ? ...

Gruß
Peter

[implementation]

Zitat:

Zitat von hanspeter (Beitrag 1061213)

Beispiel
dll/bpl A enthält Fastreport
dll/bpl B enthält Fastreport
Fastreport registriert sich über Registerclass

Modul A kann problemlos verwendet werden.
Modul B kann problemlos verwendet werden.

Wird versucht eines der beiden Module nachzuladen, wenn das jeweils andere Modul bereits geladen ist, dann knallt es und die Anwendung stürzt ab.

Wie wäre es, einen Fastreport-Wrapper zu bauen?
Sowohl das Hauptprogramm als auch die DLLs kennen bestimmte Interfaces.
Das Hauptprogramm besitzt Klassen, die diese Interfaces implementieren.
Das Hauptprogramm ruft dann einfach eine bestimmte DLL-Funktion auf und übergibt die Interfaces als Parameter.
... und schon läufts!
Genauso auch mit Formularen.

[hanspeter]

Zitat:

Zitat von implementation (Beitrag 1061216)

Wie wäre es, einen Fastreport-Wrapper zu bauen?

Genauso auch mit Formularen.

So haben wir es letztendlich realisiert.
Aber warum mit viel Aufwand um die Unzulänglichkeiten eines Entwicklungssystem herum programmieren.
Nur um das zu erreichen, was in moderneren Systemen Standard ist?

[plusplus]

I love working with DLL's and I don't understand why there are so many against it. It is robust and flexible. You can plug in C DLL or Delphi DLL. Same with BPL.

Abstract and dynamic loading is the key. Once you know your way around your app can be a plug and play solution that is not only performing well but also fun to maintain.

[plusplus]

@Peter - You are right with BPL's with DLL you don't have that problem you are describing and DLL's work fine even with different compilers.

[Tossi]

Hey,
echt super, dass Ihr alle mitmacht. Mir ist da eine Idee gekommen. Nur die Umsetzung??

In der Exe habe ich eine globale StringListe. Wenn ich mein Modulverzeichnis scanne und alle Module lade merke ich mir
Modulname und den Zeiger. Im LoadLirary wird dann für jede Form die initialization aufgerufen. Kann ich nicht hier etwas machen, um die Formulare auch in einer Liste zu haben?? Leider habe ich im Initialization noch kein Zugriff auf die Klasse oder??

[Tossi65]

So ein Problem gelöst nu kommt ein neues.

Delphi-Quellcode:

procedure LadeModule;
var
  StrPfad: String;
  StrSuchPfad: String;
  SR: TSearchRec;
  FileAttrs: Integer;
  AHandle : Cardinal;
begin
  StrPfad := IncludeTrailingPathDelimiter( ExtractFilePath(ParamStr(0)))+ 'Module\';
  FileAttrs:= faAnyFile;
  StrSuchPfad := StrPfad + '*.mod';
  if FindFirst(StrSuchPfad, FileAttrs, SR) = 0 then
  begin
    repeat
      try
        if (SR.Attr and FileAttrs) = SR.Attr then
        begin
  //        AHandle := LoadLibraryEx(PChar(StrPfad + Sr.Name),0,LOAD_LIBRARY_AS_DATAFILE);
          AHandle := LoadLibrary(PChar(StrPfad + Sr.Name));
          if AHandle > 0 then
          begin
            FModulListe.AddObject(Sr.Name,Pointer(AHandle));
            //Warum kracht es hier bei LoadLibrary??
            FreeLibrary(AHandle);
          end;
        end;
      except

      end;
    until FindNext(SR) <> 0;
    //Warum kracht es hier??
    FindClose(SR);
  end;
end;

Ich lade meine Module in eine Liste. Eigentlich kein Problem. Ich muss eigentlich mit LoadLibrary benutzen, damit die Initialisierung in den Forms der Module aufgerufen wird. So werden Die Forms in eine 2. Liste aufgenommen. Bis hierher
geht alles aber dann mit FreeLibrary() kommt dann eine Fehler bei Ardesse 000000!?!?!?!?!

Auch wenn ich die Registrierung im Modul ausmache. Mit LoadLibraryEx kommte der Fehler nicht.

Und dann kracht es bei FindClose mit "ungültiger Zeiger".

Kein Plan

[implementation]

Zitat:

Zitat von Tossi65 (Beitrag 1061649)

Delphi-Quellcode:

            //Warum kracht es hier bei LoadLibrary??
            FreeLibrary(AHandle);

Ähem, wenn du FreeLibrary hier schon aufrufst, dann kann es nachher nur krachen, weil du damit das Modul schon freigibst.
Das solltest du erst ganz am Ende, wenn das Programm beendet wird.

[Bummi]

sind die DLL's die Du hier testweise lädst initialisiert?

Delphi-Quellcode:

library Test;
var
 SaveDllProc: Pointer;
 procedure LibExit(Reason: Integer);
begin
 if Reason = DLL_PROCESS_DETACH then
  begin
    .
                .   // Exit-Code für Bibliothek
                . 
  end;
   SaveDllProc(Reason);     // Speichern der Eintrittspunkt-Prozedur
  end;
 begin
    .
                .             // Code für die Initialisierung der Bibliothek
                .
  SaveDllProc := DllProc;       // Speichern der Kette von Exit-Prozeduren
  DllProc := @LibExit;      // Installieren der LibExit-Exit-Prozedur
 end.

[Tossi65]

@implementation
Ja das ist richtig. Ich rufe Loadlibrary auf damit die Initialisierung im Modul ausgeführt wird. Dabei werden alle
Formulare im Modul in eine Liste gespeichert.
Danach brauch ich das Handle eingentlich nicht mehr.

@Bummi
wofür ist die Funktion?