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