Plugin-System fragen

[b1428727]

Hallo und guten tag zusammen...

ich mache mir gedanken über ein plugin-system welches ich in meine anwendung integrieren möchte.
habe mir hier im forum auch schon beispiele angesehen wie dies funktionieren könnte.

aber es gibt da eine spezielle hürde, welche ich noch nicht bewältigt habe.

problem
wie kann mann plugins einbinden welche

• a. in möglichst jeder sprache geschrieben werden können (pascal und c würden mir reichen)
  b. fenster enthalten
  c. diese fenster (b) an mein haupt-formular gedockt werden können
  d. diese gedockten fenster (c) unpinnbar sind

info zu d: pin-klicken sodass diese wie in delphi nach links sliden und keinen platz mehr brauchen


mögliche lösung, ole-variante
ich habe mir gedacht, diese ole schnittstelle wäre ja prima geeignet.
mann kann in verschiedenen sprachen ein ole-objekt erzeugen, somit wäre punk a erfüllt.

ich könnte ein formular in meiner eigenen anwendung erzeugen, somit wäre punkt b,c und d erfüllt.
auf diesem formular platziere ich einen ole-container welches dann das ole-objket vom plugin enthält.

das ole-objekt müsste wohl ein activeform sein, somit kann es sich selber im ole-container zeichnen und dort
ausgeführt werden.

problem an dieser geschichte ist:
wenn ich das ole objekt erzeuge z.b. ein "word.document", oder ein "excel.sheet" funktioniert das
wunderbar in meinem formular, jedoch sobald dies gedockt wird, gibt es probleme.
habe auch ein eigenes activeform objekt in einer bibliothek erstellt und dies in den ole-container
geladen. auch damit funktioniert es nur bis das fenster gedockt wird.

sobald das formular mit dem ole-container gedockt wird, verschwindet der inhalt
vom ole-container. (mit DoVerb(ovShow) wird dann auch nurnoch das menü vom word angezeigt aber
das dokument ist wegg).

ich erkenne die inkompatibilität vom ole-container/-inhalt zum docken nicht.
was können da die ursachen sein? kann mann diese umgehen oder ist es grundsätzlich mit ole-container nicht möglich?

andere varianten
sind mir bisher noch nicht in den sinn gekommen. aber evtl. gibt es eine andere lösung, ohne ole
welche meine wünsche a-d erfüllen könnte?


vielen dank für jeglichen input.

grüsse

[himitsu]

Zitat:

a. in möglichst jeder sprache geschrieben werden können (pascal und c würden mir reichen)

DLL und alles über Interfaces (statt String verwende besser den WideString, da der String erstmal nicht über EXE-DLL-Grenzen hinweg verwaltbar und dazu noch ein delphieigener Typ ist).
Du darfst also nur Typen und Methoden nutzen, welche überall existieren.

Zitat:

b. fenster enthalten

Das schließt sich mit A etwas aus, es sei denn du arbeitest NonVCL und oder die Fenster der DLL/Prlugins interagieren nicht mir denen der EXE/Anwendung.

Am Einfachsten, stelle eine Schnittstelle her, über welche die Plugins eine Form zusammenbasteln können.
So mit Funktionen wie ErstelleFenster, ErstelleEdit ... und die Callbacks (die Ereignismethoden ala OnClick wieder über ein Interface im Plugin weiterleiten)
Und schon hast du auch C und D gelöst, da dieses direkt in der Anwendung verwaltet werden kann.
So sind zwar nur "einfache" Fenster möglich, aber immerhin ist dann alles aus einer Hand und eine Anwendung behält die vollte Kontrolle. (ist z.B. gut, falls irgendwann auch noch Themes, bzw. eine Design-Enginge eingesetzt werden sollen)


PS:
http://www.delphipraxis.net/internal...lugin+tutorial
http://www.delphipraxis.net/internal...lugin+tutorial

Und willkommen an Board

[mkinzler]

Zitat:

(statt String verwende besser den WideString, da der String erstmal nicht über EXE-DLL-Grenzen hinweg verwaltbar und dazu noch ein delphieigener Typ ist...)

Ein delphieigener typ ist es nunmal aber nicht, sondern eine OLE-Typ.

[Bernhard Geyer]

Sollte alles (u.U. mit viel Aufwand) möglich sein. Unsere eigenes Plugin-System kann Fenster von DLL's (C-Kompatible schnittstelle) in Hauptformular einbetten und unterstützt Shortcuts + Tabs. Tiefgreifende Delphi+Win32-API-Kenntnisse und 1-2 Wochen für das Fensterhandling sind schon nötig.

[blackfin]

Eine andere Möglichkeit für ein Plugin-System ist die Erstellung einer eigenen API für das Programm, die du dann über eine Scriptsprache nach aussen trägst.
So etwas in der Art habe ich mal mit Delphi + Scriptsprache Lua gemacht, klappt wunderbar.

Es ist natürlich ein relativ hoher Aufwand, die ganzen Funktionen, die per Scriptscprache zur Verfügung stehen sollen, nach Aussen zu tragen, allerdings hast du dadurch die volle Kontrolle, was deine Plugins dürfen und was nicht.

Fenster, deren Elemente und Ereignisroutinen könntest du über XML beschreiben, die Eventhandler auf Lua-Funktionen legen und in diesen Wiederum die Applikations-API aufrufen.
So in etwa funktioniert auch z.B. das Plugin-System von World of Warcraft, die gesamten Addons werden darüber geschrieben.

[b1428727]

Vielen dank für eure antworten.

Zitat von himitsu:

...
Am Einfachsten, stelle eine Schnittstelle her, über welche die Plugins eine Form zusammenbasteln können.
So mit Funktionen wie ErstelleFenster, ErstelleEdit ... und die Callbacks (die Ereignismethoden ala OnClick wieder über ein Interface im Plugin weiterleiten)
Und schon hast du auch C und D gelöst, da dieses direkt in der Anwendung verwaltet werden kann.
So sind zwar nur "einfache" Fenster möglich, aber immerhin ist dann alles aus einer Hand und eine Anwendung behält die vollte Kontrolle. (ist z.B. gut, falls irgendwann auch noch Themes, bzw. eine Design-Enginge eingesetzt werden sollen)
...

Das ist mir viel zu viel aufwand. ich befürchte auch, dass die plugin-hersteller dann immer mehr wünsche
haben werden bezüglich zur verfügung stehender controls. im sinne von bitte bau uns noch ein ErstelleTreeview,
ErstelleImage, ErstelleX, ErstelleURLLabel, ErstelleYZ, etc... ich möchte noch events für OnMouseOver, OnEnter, OnXYZ, etc...

darum habe ich mir gedacht, wenn ich dies über einen ole-container mache, können die plugin-hersteller
programmieren was sie wollen und auch so wie sie es in deren sprache bereits gewohnt sind...
und sie können alle Controls benutzen die sie in ihrer sprach-umgebung haben.

Zitat von Bernhard Geyer:

Sollte alles (u.U. mit viel Aufwand) möglich sein. Unsere eigenes Plugin-System kann Fenster von DLL's (C-Kompatible schnittstelle) in Hauptformular einbetten und unterstützt Shortcuts + Tabs. Tiefgreifende Delphi+Win32-API-Kenntnisse und 1-2 Wochen für das Fensterhandling sind schon nötig.

diese eingebundenen fenster können dann auch an das hauptformular gedockt werden? so ähnlich wie in delphi?
auch mit der funktion unpinn, pinn (also wegg-sliden und wenn mit maus auf das DockTabSet wieder erscheinen?)
Da gibt es keine probleme?

kann auch in einem teil (container z.b. scrollbox) eines fensters der hauptanwendung das fenster der plugin-dll
angezeigt werden? das wollte ich nämlich auch noch. sodass ich z.b. ein Einstellungen-Fenster in meinem programm habe
mit diversen tabs z.b. Allgemein (meins), Erweitert (meins), Drucken (von Plugin-Drucken), Mailen (von Plugin-Email), etc.

Zitat von blackfin:

Eine andere Möglichkeit für ein Plugin-System ist die Erstellung einer eigenen API für das Programm, die du dann über eine Scriptsprache nach aussen trägst.
So etwas in der Art habe ich mal mit Delphi + Scriptsprache Lua gemacht, klappt wunderbar.

Es ist natürlich ein relativ hoher Aufwand, die ganzen Funktionen, die per Scriptscprache zur Verfügung stehen sollen, nach Aussen zu tragen, allerdings hast du dadurch die volle Kontrolle, was deine Plugins dürfen und was nicht.

meine plugins dürfen in einem definierten container eigentlich machen was sie wollen.



die idee dies mit active-forms zu lösen wäre doch eigentlich gut, oder meint ihr nicht?
der internet explorer hat auch so eine funktionalität. flash und solche inhalte werden
dort auch eingebunden (vermutlich auch über diese activeforms) und die können dann in ihrem rahmen machen was sie wollen.

hier ist noch ein beispiel auf welches ich mal gestossen bin wie man mit delphi eine control im internet explorer erzeugt über
activeforms http://delphi.about.com/od/interneti...l/aa042099.htm
das scheint mir eine super lösung zu sein, wenn da nur nicht dieses docking-problem wäre.

und der aufwand ist auch sehr klein, mann braucht nur einen TOleContainer und die angabe,
welches objekt darin angezeigt werden soll.

ein normales fenster kann ich docken, aber wenn auf dem form ein olecontainer ist, dann verschwindet der inhalt
nach dem docken und manchmal stürzt auch der ole-server ab (z.b. word)

[b1428727]

habe nun herausgefunden dass selbst das docken eines formulars mit einer twebbrowser-komponente
nicht richtig funktioniert. bzw. die webbrowser komponente wird nach dem eindocken sofort zurückgesetzt.

ich bekomme langsam zweifel daran, dass mann ole und docking überhaupt verbinden kann...

habe auch noch den Jedi docking manager ausprobiert (TJvDockServer mit TJvDockClient),
aber auch hier verschwindet der inhalt vom twebbrowser.

[implementation]

Ich habe sowas bisher immer so geregelt, dass ich ein paar Interface zu jedem Zweck gebastelt habe (z.B. eins für Dock-Fenster, eins für Label, usw.) + ein Factory-Interface deklariere und beim Start des Plug-Ins die Factory übergebe.

Delphi-Quellcode:

type
  IFactory = interface
    function CreateDockWindow: IDockWindow;
    ...
  end;
  IDockWindow = interface
    function GetCaption: string;
    procedure SetCaption(val: string);
    property Caption: string read GetCaption write SetCaption;
    ...
  end;

type
  TFactory = class(TInterfacedObject, IFactory)
    ...
  end;
  TDockWindow = class(TInterfacedObject, IDockWindow)
    ...
  end;

Die Interfaces kann dann jeder Plug-In-Entwickler in seiner Sprache deklarieren.
Außerdem können die Plug-Ins schön klein bleiben, da ein Delphi-PlugIn dann z.B. keine VCL braucht, ein VC++-PlugIn keine MFC/WTL usw.

[b1428727]

aber auch diese methode schränkt ja die plugin-entwickler auf die vom interface zur verfügung gestellten komponenten ein.

es wäre doch toll, wenn die plugin-entwickler ihre eigenen objekte/komponenten nutzen könnten.
dann habe ich weniger aufwand und die plugin-ersteller müssen nicht meine interface-deklarationen lernen.

[b1428727]

die feststellung mit der webbrowser komponente hat mich auf eine seite geführt.
diese erklärt warum docking und ole-(activeforms) nicht funktioniert!

das problem ist delphi.

denn delphi zerstört beim docken alle window-handles (habs selber nicht überprüft)
und erstellt diese dann neu!

die objekte im ole-container halten eine solche prozedur nicht aus und zeigen
danach fehler.

als möglicher lösungsvorschlag wurde das verschieben von activex objekten
in ein anderes formular genannt. also vor dem docken die objekte in ein
anderes formular packen und nach dem dock-vorgang die objekte wieder zurückschieben.

hier der link zu der seite welche dieses problem umschreibt (englisch):
http://community.devexpress.com/foru...053/30661.aspx

es ist ein bisschen ein gebastel, aber ich werde mal probieren ob ich das hinkriege...
ansonsten müssen halt entweder die kunden auf das docking verzichten oder aber
ich erstelle die docking-formulare selber und die pluginhersteller können
über ein interface halt nur daten in eine von mir vorgegebene struktur passen...
ole-container dürften halt dann nur in nicht-dockbaren fenstern vorkommen...


vielen dank für eure hilfen

gruss