Welche Daten zwischen Plugin Anwendung?

[Flippo]

Hallo,

ich habe eine Anwendung die so konzipiert ist, dass sie durch Plugins in Form von Dlls erweiterbar ist. Zwischen Plugin und Anwendung können Strings und Integer Werte in beide Richtungen ausgetauscht werden und damit kann ich eigentlich alles was mir als Plugin so einfällt bewältigen. Nun möchte ich hinterher nicht mit einer schon komplexen Anwendung und vielen Plugins dastehn, noch eine Idee haben und diese nicht umsetzen können, weil ich im Grundgerüst die Möglichkeit für die Übergabe bestimmter Parameter nicht eingeplant habe.

Meine Frage an euch deshalb: Unter der Forraussetzung, dass alle Plugins ihre Grafischen Teile in einer eigenen Form darstellen und über diese auch mit dem User kommunizieren können, was für Informationstypen könntet ihr euch vorstellen, die zwischen Hauptanwendung und Plugins übermittelt werden müssten bei irgendeinem erdenklichen Plugin.

MFG

Flippo

[gsh]

mach es so wie auch und mach es flexibel :mrgreen:

Ja ich gebs zu die Idee ist nicht auf meinem mist gewachsen sondern das Trillian Team ist auf die Idee gekommen.
Trillian Plugin SDK: http://www.trillian.cc/support/sdkmanual.php
Dort kann man sehen das sie eine Unit öffentlich machen wo für jede MSG ein struct (also ein record) besitzt.
Nun kann man die Plugin procedure mit zwei parameter ALLES was man will übergeben.
1. Parameter: Der Befehl z.b. als PChar
2. Parameter: Ein Pointer auf das Record

Nun muss das Plugin einfach nur den Befehl erkennen und dann den Pointer je nach dem verwenden

BSP: (nicht getestet)

Delphi-Quellcode:

If Befehl = '1' then
begin
  ShowMessage(TRecordBefehl1(Parameter2).Text+TRecordBefehl1(Parameter2).Text2);
end;
If Befehl = '2' then
begin
  ShowMessage(TRecordBefehl2(Parameter2).wasanderes+TRecordBefehl2(Parameter2).asdf);
end;

Ich hoff du verstehst wie ich es meine. Viel Spass

[DP-Maintenance]

Dieses Thema wurde von "Christian Seehase" von "Klatsch und Tratsch" nach "Programmieren allgemein" verschoben.
Besser in \\"Programmieren allgemein\\" aufgehoben

[gsh]

so hab mich jetzt überwunden und einen CodeLib eintrag geschrieben
hab eh nur 2 1/2 stunden dafür gebraucht :mrgreen:

http://www.delphipraxis.net/internal...t.php?p=581271

[rage2001]

Hey Flippo

Zwar habe keine Antwort, aber eine Frage. Du schreibst Dein Plugin kann mit der Anwendung reden. Da würde mich interessieren, wie Du das machst. ICh habe ein ähnliches Problem zu lösen und versuche es gerade mit einer Callback-Funktion, aber so richtig befriedigt mich das nicht.

cu rage

[gsh]

schau mal in der CodeLib vorbei
dort siehst du wie ich es gemacht habe (und es funktioniert)

[Der_Unwissende]

Hi,
ich denke sich ein Vorbild an schon bestehenden Systemen zu nehmen ist schon der richtige Ansatz. Ein sehr einfaches Beispiel für solche Systeme wäre wohl schon die IDE vor der du sitzt. Hier kannst du so ziemlich alles per Plugin einbinden.

Für ein Plugin System bietet sich ein API deiner Anwendung an. Du könntest dir z.B. von deinem Programm ein Control zurückgeben lassen, auf das eigene grafische Elemente dürfen. Diese fügst du dann ganz normal (im Plugin) ein. Hier ist natürlich dann wahrscheinlich schon eine deutliche Bindung an Delphi (je nachdem wie du das angehst). Die eigentliche Flexibilität hängt dann letztlich von deinem API ab.
Hier solltest du dir ruhig ein paar Design Patterns anschauen. Ein Observer ist zum Beispiel ideal für Plugins, aber es gibt da noch so ein paar die gut in Frage kommen. Nur um den Observer als Beispiel etwas auszuführen, mittels diesem Pattern könntest du für jedes Ereignis das von Plugins behandelt werden darf einen oder mehrere Beobachter schreiben. Ein Plugin wäre also der Beobachter. Das Ereignis ist das zu Beobachtende. Die eigentlichen Beobachter registrieren sich beim Beobachteten und werden dann alle benachrichtigt, wenn das Ereignis eintritt.
Alle Conrrolls, auf die jmd. zugriff hat, kannst du entweder direkt per Funktion zugänglich machen (dann hätten die Plugin Schreiber schon eine ganze Menge Freiheiten). Oder du erstellst einfach Methoden, die z.B. einen Menüeintrag hinzufügen. Hier kannst du dann per API festlegen, was die mit übergeben dürfen (für ein Menü z.B. der Eintrag in der Menüleiste, der Unterpunkt und die Methode die bei einem Klick aufgerufen werden soll).

Gruß Der Unwissende

[rage2001]

Hey

Zitat:

schau mal in der CodeLib vorbei
dort siehst du wie ich es gemacht habe (und es funktioniert)

Das es funktioniert ist mir schon klar, aber mein Problem ist eher das das Plugin selbst Daten schicken soll und zwar ohne von der Hauptanwendung dazu aufgefordert zu werden.
Wie ich mein Plugin beauftragen kann Daten an mich zu senden weiß ich wohl funktion=(var bla:String);
Bis jetzt löse ich das so, das ich die Plugins alle 250 ms befrage. Das ist aber nicht unbedingt der Geschwindigkeit zuträglich.

cu rage

[Flippo]

Hi, sry konnte gestern nicht reingucken...

also wie ich die Daten unaufgefordert hin und her sende: Das mache ich üüber WM_Copydata

Zum senden:

Delphi-Quellcode:

procedure TForm1.SendData(S:String);
var
   copyDataStruct : TCopyDataStruct;
begin
   copyDataStruct.dwData := 0; //use it to identify the message contents
   copyDataStruct.cbData := 1 + Length(s);
   copyDataStruct.lpData := PChar(s);
   sendmessage(PH,WM_COPYDATA,application.handle,Integer(@CopyDataStruct));
end;

Zum empfangen:

Delphi-Quellcode:

procedure WMCopyData(var Msg :TWMCopyData); message WM_COPYDATA; //Bei der Deklaration unter Form auf den Message Typ achten

Delphi-Quellcode:

procedure TForm1.WMCOPYDATA(var Msg: TWMCopyData);
var s:string;
begin
  s := PChar(Msg.CopyDataStruct.lpData) ;
end;

Danke für alle antowrten werd mir die Sachen mal angucken

MFG

Flippo

[jbg]

Zitat:

Zitat von Flippo

also wie ich die Daten unaufgefordert hin und her sende: Das mache ich üüber WM_Copydata

Für DLLs, die im selben Adressraum sind, ist das ein wenig übertrieben. Warum SharedMemory erzeugen, die Daten hineinkopieren, die Message abschicken und empfangen, die Daten aus dem SharedMemory wieder einlesen und den SharedMemory freigeben.
Da tut es ein einfaches SendMessage(AnderesFensterHandle, WM_MYUSERDEFINEDMESSAGE, 0, Longint(PChar(S)); auch. Und da wird nichts unnötig kopiert.

Zitat:

Zitat von Der_Unwissende

Ein sehr einfaches Beispiel für solche Systeme wäre wohl schon die IDE vor der du sitzt.

Und diese IDE nutzt BPLs, womit ihr alle wege offenstehen: Keine Probleme mit der Speicherverwaltung, man hat nur ein Application Objekt, man kann auf alle Units der anderen Packages (sofern eine .dcp Datei vorhanden ist) zugreifen und das in alle Richtungen. Nur auf die EXE-Selbst kann man nicht zugreifen. Die kommuniziert aber auch nur mit den Plugins über Service-Interfaces und Notifier (=Observer).
Und das beste für eigene Programme ist, dass der Compiler einem die ganzen exports und "function bla; external blo" abnimmt. Auch Klassen können über Packages hinweg instanziert werden. All das lässt sich mit einem eigenen Plugin-System nicht so ohne weiteres erreichen. Der einzige Nachteil ist, dass andere Programmiersprachen erstmal außen vor sind, bzw. halt nicht den vollen Funktionsumfang nutzen können. Aber auch unterschiedliche Delphi Versionen haben bei BPLs Probleme, weil sie einfach eine andere VCL und RTL Version als BPL benötigen.