Hallo zusammen,
gibt es eine Möglichkeit in Windows einen Alias für eine COM-Anwendung
anzulegen? Beispiel:
im Code wird diese Zeile ausgeführt:
$comObj = new COM("ExcelXXX.Application")
"ExcelXXX" gibt es auf dem System nicht. Ein Alias in Windows soll das
Systen dazu veranlassen, als wäre ExcelXXX.Application >
Excel.Application.
Das ist nur ein Beispiel und erreicht werden soll, dass die Änderung von
außen gemacht wird und nicht im Code der das Objekt erzeugt.
Viele Grüße,
Peter
Du musst "nur" eine andere COM-Anwendung schreiben, die sich als
"ExcelXXX.Application" verkauft, bzw. Dir mal die Registry-Einträge
Deiner COM-Anwendung ansehen. Da wird irgendwo eine GUID mit einem
Klartextnamen verknüpft, also beispielsweise "Bubufunz.Application".
Von dieser Definition kannst Du eine Kopie anlegen, die die gleiche GUID
mit eben "ExcelXXX.Application" verknüpft.
Allerdings:
Das ist ein reichlich aussichtsloses Unterfangen, denn eine Anwendung,
die das Excel-Objektmodell nutzt, nutzt viele weitere über die
COM-Schnittstelle definierte Objekte, die Du allesamt aufrufkompatibel
nachbilden musst.
Bist Du Dir sicher, daß Du das tun willst?
...ja, das hätte ich auch schon als "Lösung" gesehen. Aber ich wollte
kein "proxy-artige"-Anwendung für diesen Zweck in der alles nachgebildet
und weitergegeben werden muss. Deshalb die Frage, ob man nicht einfach
einen Alias irgendwo hinterlegen kann (Registry o.ä.)...
Ich bin mir nicht sicher, ob Du die Problemlage verstanden hast.
Einen Alias einrichten ist simpel (Du musst nur die GUID Deiner
gewünschten Applikation mit dem Klartextnamen "ExcelXXX.Application"
verknüpfen), aber so für sich reichlich sinnlos, weil die Anwendugn, die
diese Schnittstelle nutzen will, natürlich ein gewisses Objektmodell
erwartet, d.h. Funktionen aufrufen will, die das Objekt zur Verfügung
stellt.
Wenn Du aber beispielsweise ein Alias auf Notebook.exe als
ExcelXXX.Application verkaufst, dann funktioniert die ganze Chose nicht.
Wenn Du ein C-Programm mit einer Library XY linken willst, die aber
nicht hast, sondern stattdessen eine völlig andere Library ABC
verwendest, hilft es nicht, wenn Du ABC zu XY umbenennst. Nichts anderes
aber würde Dein "Alias"-Versuch anstellen.
Hallo Rufus,
ich denke, dass ich Dich richtig verstanden hätte:
ich könnte eine "leere" Applikation anlegen, die dann als "ExcelXXX"
registriert ist. nachdem diese aber funktionell "leer" ist könnte ich
sie zwar instanziieren, aber hätte nur die Funktionalität von dieser
leeren APP. Wenn ich z.B. ->createNewDocument oder sowas aufrufen wollen
würde, dann müsste ich diese Methode implementieren und ggf. an die
echte "Excel" "weiterleiten" etc...
Ist das das so wie du es gemeint hast?
Gruß
Peter
Zumindest den ersten Teil meine ich so; ja: Du müsstest jede aufgerufene
Funktion und jedes erzeugte Objekt mit wiederum den dazugehörigen
Funktionen nachbilden.
An ein Excel weiterleiten? Ich denk' Du hast kein Excel?
Ah, verschiedene Versionen.
Das ist zumindest bei Office-Programmen kein großes Problem, da gibt es
sowieso Alias-Einträge, nämlich welche mit und welche ohne
Versionsnummer. Von gewissen Abweichungen abgesehen sind die
COM-Interfaces der verschiedenen Generationen der Office-Anwendungen
versionsübergreifend kompatibel; ich habe eine Anwendung, die Word per
Automation steuert und das mit allen Word-Versionen seit Word 2000 ohne
größere Änderungen.
Wenn der Programmierer der "umzubiegenden" Anwendungen das
Automationsobjekt mit versioniertem Namen ansteuert, hat er sich dabei
entweder was gedacht (weil er versionsspezifische Funktionalität nutzt)
oder nicht nachgedacht (mangels Erfahrung etc.) ...
Bei mir wäre es der Sprung von Adobe Indesign CS6 auf Indesign CS7 (CC).
Da existieren meines Wissens nach solche Aliase nicht. Das mit der
Kompatibilität ist in dieser Reihe ähnlich, wenngleich es schon manche
Versionssprünge gibt, wo sich auch mal mehr ändert.
Eine eigene Frage?
Dieser Thread ist über 12 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.