Variante 1.)
Dein Zusatzprogramm könnte doch auch als Proxy programmiert werden.
Es bietet also genau das gleiche Interface wie das Plugin an und kann damit anstelle des Plugins von der Thirdparty.exe geladen werden.
Das Zusatzprogramm ruft nun seinerseits das Plugin auf und leitet alle Methodenaufrufe mehr oder weniger 1:1 weiter.
Code:
ThirdParty.exe -> Zusatzprogramm (Proxy) -> Plugin
Das bedeutet natürlich, dass ThirdParty.exe dazu gebracht werden muss, dein Zusatzprogramm zu laden/starten.
Vorteil: du kannst jede Kommunikation zwischen ThirdParty.exe und Plugin überwachen und eingreifen.
Nachteil: man kann nicht dynamisch zur Laufzeit das Zusatzprog starten.
Variante 2.)
Dein Plugin hat zusätzlich zum Interface IPlugin ein weiteres Interface IDiagnose.
Die CoClass muss also beide Interfaces implementieren.
Wenn das Plugin-Objekt erzeugt wird, legt es seinen Interfacepointer in der Running Object Table (ROT) ab.
Wird das Objekt zerstört, entfernt es sich selbst aus der ROT.
Jetzt kommt das Zusatzprogramm und sucht das Objekt in der ROT (mit GetObject()).
Dies ist wichtig, damit sowohl ThirdParty.exe als auch Zusatzprog mit dem gleichen Objekt arbeiten.
Bei Erfolg nimmt es den Interfacepointer und wandelt ihn nach IDiagnose.
Das Zusatzprogramm kann nun über IDiagnose Änderung im Plugin vornehmen (z.B. Properties abfragen und setzen).
Damit das Plugin auch seinerseits mit dem Zusatzprog sprechen kann, bietet das Zusatzprog ein
Objekt mit dem Interface IDiagnoseHost an.
Delphi-Quellcode:
IDiagnose = Interface
function Getxxxx:integer; // irgendwas auslesen
procedure Setxxxx(value:integer); // oder setzen
procedure SetDiagHost(value:IDiagnoseHost); // Objekt für Callback
end;
Das Plugin merkt sich den Interfacepointer von SetDiagHost und hat nun die Möglichkeit
beliebige Methoden über IDiagnoseHost im Zusatzprogramm aufzurufen.
Dieses Vorgehen mit einer Callback-Schnittstelle ist einfacher zu handeln als
COM-Events.