Wir haben eine .NET C # -Anwendung, die die Adobe ActiveX-Steuerelemente verwendet. Für die Versionen 7-10 von Adobe Acrobat und Adobe Reader mussten Sie zur Verwendung dieses Steuerelements die Einstellung "PDF im Browser anzeigen" aktivieren. Sie können dies manuell über die GUI mit
tun %Vor%oder programmgesteuert, indem Sie die Registrierungseinstellungen direkt festlegen
%Vor% Dies folgt der SDK-Referenz Ссылка . Unsere Anwendung verwendet die programmatische Einstellung dieses Registrierungswerts, wenn unsere Kunden die Versionen 7-10 von Adobe Reader oder Adobe Acrobat haben. Der obige Link zeigt außerdem an, dass dieser bBrowserIntegration -Registrierungsschlüssel in XI (11) veraltet ist. Der alte Registrierungspfad existiert immer noch in den neuen Versionen, d. H .:
Es gibt jedoch nicht mehr den Schlüssel bBrowserIntegration , wie in der Dokumentation angegeben, sondern veraltet.
Es sieht so aus, als ob das Adobe ActiveX Control immer noch gut mit XI und DC funktioniert, solange die Option "PDF im Browser anzeigen" wie immer aktiviert ist.
Für die Versionen XI (11) und DC gibt es zwei veröffentlichte Links, die deutlich zeigen, wie man manuell erreicht:
%Vor% Wenn wir beim Testen von Adobe Reader DC die Schritte zum Aktivieren der PDF-Anzeige im Browser für eine neue Kundeninstallation nicht ausführen, wird unsere Anwendung COM error und dann, wenn wir die Einstellung aktivieren, den Anweisungen in folgen Der obige Link funktioniert wie erwartet mit unserer Anwendung, es rendert PDFs mit dem Adobe ActiveX Control, was ähnlich aussieht wie in älteren Versionen (7-10), wenn die Registrierungseinstellung nicht eingestellt wurde (siehe mein alter Beitrag) und meine eigene Lösung damals Wie erkennt man Ursache, Behebung oder Umgehung des Adobe ActiveX / COM-bezogenen Fehlers 0x80004005 progamatisch? ).
Also bleibt die Frage, was ist das erwartete programmatische Äquivalent für den manuellen Prozess in XI oder DC heute oder das Äquivalent zu dem, was in 7-10 funktionierte, indem man die Registrierungseinstellung bBrowserIntegration entsprechend einstellt. Wir möchten es aktivieren und es dann auf die vorherige Einstellung zurücksetzen, wenn unsere Anwendung beendet wird (so dass unsere Anwendung den Benutzer nicht dazu zwingt, die Einstellung beizubehalten, nur weil unsere Anwendung sie benötigt), was wir heute für 7 tun -10.
Ich kann anscheinend keine Online-Referenzen finden, um die Browserintegration vom Standpunkt des Entwicklers aus zu aktivieren / deaktivieren, damit unsere Anwendung weiterhin das ActiveX-Steuerelement verwenden kann und die COM-Fehler nicht angezeigt werden und den Benutzer zu Änderungen zwingen dies manuell.
Die primäre Priorität besteht darin, die Lösung für DC zu verstehen, da dies das neue Paradigma für Adobe Acrobat / Reader darstellt.
Haben Sie die Verwendung von " Registrierung kostenlos " Szenario in Betracht gezogen? Es ermöglicht die Verwendung von COM / ActiveX-Komponenten in Ihrer Anwendung, ohne das ActiveX global zu registrieren, und ermöglicht das Laden des isolierten COM / ActiveX-Steuerelements für Ihre Anwendung nur basierend auf den im XML-Manifest definierten Schnittstellen, die in Ihrer Anwendung enthalten sind.
Siehe diesen Beitrag für die Liste der Tools und dieser Beitrag für das Beispiel-XML-Manifest zur Verwendung des Flash-Plugins und dieses Schritt für Schritt Anleitung . Ich gehe davon aus, dass Sie für die Steuerung von Adobe Reader den Ordner PDF.ocx aus dem Ordner C: \ Programme \ Adobe \ Acrobat \ Reader \ ActiveX verwenden sollten.
UPDATE (27. Juli 2015): In den neuesten Versionen von Adobe Reader verwenden sie AcroPDF.dll und verschoben es in \ Programme \ Gemeinsame Dateien \ Adobe \ Acrobat \ ActiveX \, wie ich mit Adobe Reader 11 überprüft habe. Leider AcroPDF.dll gibt einen Fehler aus, wenn Sie versuchen, es mithilfe von regsvr32.exe zu installieren. Ich nehme an, es überprüft einige zusätzliche Schlüssel vor der Initialisierung, um vor nicht erlaubter Verwendung zu schützen (bis Benutzer das Steuerelement in IE freigibt). Scheint so, als gäbe es nicht offiziell und programmatisch die Forderung, dass Benutzer die PDF-Steuerung explizit für die Verwendung durch Nicht-Adobe-Apps zulassen dürfen.
Siehe auch die Diskussion zu möglichen Problemen auf der x64-Plattform: Die bessere und zuverlässigere Methode ist die Verwendung der Adobe Reader-Steuerung indirekt durch das Hosting des IE-WebBrowser-Steuerelements, das das eingebettete PDF-Viewer-Steuerelement entsprechend aufruft.