Tweet
Hallo,
in einer bereits vorher gestellten Frage wie ich den COM-Server meiner Application zur
Laufzeit ermitteln kann antwortete mir Herr Kosch außerordentlich schnell darauf.
Herzlichen Dank zunächst einmal dafür. Leider habe ich das Problem bis dato noch nicht
gelöst, deshalb möchte ich, da die vorherige Frage meiner Meinung nach nicht exakt
genug das wiedergibt, was sie eigentlich darstellt. Das Szenario ist folgendes:
Ich entwickle eine Anwendung, die zunächst weder installiert werden darf bzw. kann
und auch keinen Zugriff auf die Registry hat. Des weiteren ist auch nicht unbedingt
vorausgesetzt, dass eine Festplatte oder sonstige Speichermedien existieren (mit Ausnahme des
Speichers). D. h. ich kann keine COM-Objekte, Schriftarten usw installieren, das muss ich alles
beim Start des Programmes machen. Weiterhin unterstützt das Programm auch ein PlugIn Konzept
wofür COM-Objekte und ActiveX Elemente außerordentlich gut geeignet wären.
Des weiteren ist es aber auch möglich, sobald eine Festplatte existiert, das Programm auf
Festplatte zu installieren. Deshalb ist das Programm als COM-Server konzipiert um
später von externen Programmen darauf zugreifen zu können. Das funktioniert auch alles einwand-
frei, bis auf das, dass die TLB immer wieder flöten geht.
Nun zu dem Problem mit den PlugIns. Da ich nach einigem grüblen und nachlesen herausgefunden
habe, dass man COM-Objekte auch on-the-fly registieren kann und dazu nicht einmal Registry
Zugriff braucht (ich weiss nun leider im Augenblick die Funktion nicht mehr
Invoke... Revoke.. oder so) womnit ich von meiner Anwendung schön darauf zugreifen kann.
Da aber das COM-PlugIn auch in meiner Anwendung Aktionen ausführen soll muss praktisch mein
COM-PlugIn einen Zeiger/eine Instanz meiner Anwendung bekommen (was das größere Problem
darstellt) und meine Anwendung einen Zeiger auf das COM-PlugIn (was mehr oder weniger
nicht so problematisch ist).
Herr Kosch beantwortete die Frage mit dem COM-Server der an das PlugIn übergeben wird
so, dass ich es einfach nochmals erzeugen muss und dann einfach übergeben.
Ist es aber nicht möglich, dass der COM-Server ja ohnehin beim Start der Application schon
existiert und ich einfach irgendwie darauf zugreifen kann. Ich bin mir da nämlich nicht
ganz sicher ob ich den Zeiger über Delphi oder direkt über die Running Object Table ermitteln
kann. Somit wäre es möglich, dass ich das COM-Server-Objekt per Aggregation (so weit
ich das verstanden habe) an mein COM-PlugIn übergeben kann.
Die Fragen nun an alle: Hat jemand eine Möglichkeit gefunden ein COM-Objekt ohne Zugriff auf
die Registry zu erzeugen. Ein ActiveX Element sichtbar darzustellen. Und die Instanz auf
das aktuelle COM-Server-Objekt zu ermitteln um diesen dann an das COM-Objekt zu übergeben?
Herzlichen Dank im Voraus und sorry für den langen Text, aber den Leuten, mit ich schon
vorher sprach auch mit den Leuten von DevDays und WinSummit, war das Problem mit den oben
genannten Aspekten nicht einleuchtend genug, denn anscheinend hat so etwas vorher noch nie
jemand probiert.
Gruß, Martin Sedlmair
in einer bereits vorher gestellten Frage wie ich den COM-Server meiner Application zur
Laufzeit ermitteln kann antwortete mir Herr Kosch außerordentlich schnell darauf.
Herzlichen Dank zunächst einmal dafür. Leider habe ich das Problem bis dato noch nicht
gelöst, deshalb möchte ich, da die vorherige Frage meiner Meinung nach nicht exakt
genug das wiedergibt, was sie eigentlich darstellt. Das Szenario ist folgendes:
Ich entwickle eine Anwendung, die zunächst weder installiert werden darf bzw. kann
und auch keinen Zugriff auf die Registry hat. Des weiteren ist auch nicht unbedingt
vorausgesetzt, dass eine Festplatte oder sonstige Speichermedien existieren (mit Ausnahme des
Speichers). D. h. ich kann keine COM-Objekte, Schriftarten usw installieren, das muss ich alles
beim Start des Programmes machen. Weiterhin unterstützt das Programm auch ein PlugIn Konzept
wofür COM-Objekte und ActiveX Elemente außerordentlich gut geeignet wären.
Des weiteren ist es aber auch möglich, sobald eine Festplatte existiert, das Programm auf
Festplatte zu installieren. Deshalb ist das Programm als COM-Server konzipiert um
später von externen Programmen darauf zugreifen zu können. Das funktioniert auch alles einwand-
frei, bis auf das, dass die TLB immer wieder flöten geht.
Nun zu dem Problem mit den PlugIns. Da ich nach einigem grüblen und nachlesen herausgefunden
habe, dass man COM-Objekte auch on-the-fly registieren kann und dazu nicht einmal Registry
Zugriff braucht (ich weiss nun leider im Augenblick die Funktion nicht mehr
Invoke... Revoke.. oder so) womnit ich von meiner Anwendung schön darauf zugreifen kann.
Da aber das COM-PlugIn auch in meiner Anwendung Aktionen ausführen soll muss praktisch mein
COM-PlugIn einen Zeiger/eine Instanz meiner Anwendung bekommen (was das größere Problem
darstellt) und meine Anwendung einen Zeiger auf das COM-PlugIn (was mehr oder weniger
nicht so problematisch ist).
Herr Kosch beantwortete die Frage mit dem COM-Server der an das PlugIn übergeben wird
so, dass ich es einfach nochmals erzeugen muss und dann einfach übergeben.
Ist es aber nicht möglich, dass der COM-Server ja ohnehin beim Start der Application schon
existiert und ich einfach irgendwie darauf zugreifen kann. Ich bin mir da nämlich nicht
ganz sicher ob ich den Zeiger über Delphi oder direkt über die Running Object Table ermitteln
kann. Somit wäre es möglich, dass ich das COM-Server-Objekt per Aggregation (so weit
ich das verstanden habe) an mein COM-PlugIn übergeben kann.
Die Fragen nun an alle: Hat jemand eine Möglichkeit gefunden ein COM-Objekt ohne Zugriff auf
die Registry zu erzeugen. Ein ActiveX Element sichtbar darzustellen. Und die Instanz auf
das aktuelle COM-Server-Objekt zu ermitteln um diesen dann an das COM-Objekt zu übergeben?
Herzlichen Dank im Voraus und sorry für den langen Text, aber den Leuten, mit ich schon
vorher sprach auch mit den Leuten von DevDays und WinSummit, war das Problem mit den oben
genannten Aspekten nicht einleuchtend genug, denn anscheinend hat so etwas vorher noch nie
jemand probiert.
Gruß, Martin Sedlmair