Add-On erstellen, das auf die Funktion im Hauptprogramm zugreift?

[mjustin]

Zitat von romber:

Wie realistisch ist das alles? Wie soll der Add-On am besten aussehen? Soll das eine DLL sein oder was am besten? Wie würdet Ihr das machen?

Ein paar Anregungen sind hier zu finden:

http://stackoverflow.com/questions/3...delphi-program

Eine Open Source Lösung ist der JvPluginManager aus der Jedi JCL , der ein Grundgerüst für DLL (und BPL) Plugins bereitstellt.

http://stackoverflow.com/a/366079/80901
http://www.delphipraxis.net/901951-post.html

[romber]

@mjustin

Vielen Dank für diese Link, sehr interessant!

Die von dem Dem schönen Günther vorgeschlagene Lösung, die Add-Ons als Server zu implementieren, ist eine gute Idee. Die wäre auch sehr einfach zu realisieren. Aber wenn man als alternative noch die DLL-Schnittstelle anbieten möchte, wie greift eine Funktion in der DLL auf die Funktionen im Hauptprogramm zu?

Sagen wir, ich habe jetzt im Hauptprogramm eine Function, die als Parameter einen String erwartet. Dieses String wird dann zu einem Objekt umgewandelt, geprüft/gefiltert und dann dem Benutzer angezeigt. Wenn ich jetzt eine zusätzliche überladene Variante dieser Funktion erstelle, in der ich alle unpassende Datentypen durch Windows API kompatible Datentypen ersetze, wie kann meine DLL auf diese Funktion zugreifen?

[BUG]

Zitat von romber:

Wenn ich jetzt eine zusätzliche überladene Variante dieser Funktion erstelle, in der ich alle unpassende Datentypen durch Windows API kompatible Datentypen ersetze, wie kann meine DLL auf diese Funktion zugreifen?

Indem du dem Add-On die Adresse der Funktion gibst (z.B. als Parameter einer Initialisierungsfunktion).
Wenn du das mit mehreren Funktionen machen willst, würde ich so etwas wie ein Interface benutzen.


Solltest du wirklich DLLs und Server unterstützen wollen, würde ich mich erst einmal auf die DLL-Schnittstelle beschränken und mögliche Verbindungen zu Servern über entsprechende DLL-Add-Ons ermöglichen.

[romber]

[QUOTE=BUG;1216123]

Zitat von romber:

Indem du dem Add-On die Adresse der Funktion gibst (z.B. als Parameter einer Initialisierungsfunktion).
Wenn du das mit mehreren Funktionen machen willst, würde ich so etwas wie ein Interface benutzen.

Es wird erst mal nur eine Funktion aus dem Hauptprogramm in DLL aufgerufen. Ich denke, ich probiere es erst mal mit der esten Variante. Nennt sich das Callback-Funktion oder ist mit der Weitergabe der Adresse der Funktion an den Add-On etwas anderes gemeint?

[BUG]

Zitat von romber:

Nennt sich das Callback-Funktion oder ist mit der Weitergabe der Adresse der Funktion an den Add-On etwas anderes gemeint?

Jup, Callback-Funktion würde passen.
Ich weiß ja nicht, was du in der Funktion (in der DLL) so anstellst. Wenn die einen Thread erstellt, der dann irgendwann (nachdem die Funktion zurückgekehrt ist) die "Callback"-Funktion aufruft, würde ich nicht unbedingt mehr von Callback sprechen. Aber das ist Erbsenzählerei

[sx2008]

Also ich würde die Aufgabenstellung nochmal im Kern durchdenken.
Wie immer ist die Trennung zwischen Datentransport und Datenaufbereitung sehr wichtig.
Wieviele Arten des Datentransports sind denn denkbar?
* FTP / Secure FTP (verschiedene Clients vorsehen)
* Zugriff auf Datei, lokal oder im Netzwerk
* HTTP(s); also Download einer Resource von einem Webserver mit der GET Methode
* externes Exe-Programm, das die Daten holt
* externes VB- oder Java-Script das die Daten holt

Datenaufbereitung bedeutet dass die Daten in einen Konverter gehen und am Ende kommt das gemeinsame XML-Format raus.
Nur diesen Konverter würde ich als Plugin sehen.
Der verschiedenen Arten des Datentransports sollten dagegen fest im Hauptprogramm liegen (natürlich parametrisiert).

Das Plugin könnte man als ActiveX-DLL implementieren.

Delphi-Quellcode:

IConverterPlugin = Interface
  procedure SetParameter(name:WideString; value:OleVariant);
  procedure Convert(instream, outstream : IStream);safecall;
  function GetVersion:Widestring;safecall;
end;

[romber]

Zitat von sx2008:

Der verschiedenen Arten des Datentransports sollten dagegen fest im Hauptprogramm liegen

Das würde für mich sehr viel undankbarer Arbeit bedeuten, von der am Ende bestenfalls vielleicht 1 Benutzer von 100 Gebrauch macht. Die wichtigsten Datenquellen sind eben fest im Programm verbaut. Der Client an sich ist recht primitiv. Die Daten kosten Unmengen an Geld und sind dazu noch ziemlich kompliziert aufgebaut. Der Client macht diese Daten lesbar, und das wahr's auch schon. Ab und zu bekomme ich die Anfragen, ob es möglich wäre eine oder andere Quelle noch dazu einzubauen. Keiner ist aber bereit, den Aufwand entsprechend zu honorieren. Deswegen möchte ich ein paar Schnittstellen bereitstellen, die dem Benutzer erlauben würden, die Daten selbst woher auch immer zu beziehen und diese dann im Client genau so übersichtlich darzustellen.