PreviewHandler PDF Problem Windows 8 und höher

[Aviator]

Hallo Rollo. Ja die habe ich gesehen. Hatte das auch gestern Abend bevor ich diesen Trend hier eröffnet habe noch einmal extra probiert. Funktioniert aber leider trotzdem nicht. Bei dem Beispiel bekomme ich sogar beim Beenden des Programms eine Zugriffsverletzung in der "previewhndlr.dll" von Adobe.
Ich wäre ja froh wenn ich irgendetwas falsch mache damit das Problem schnell behoben ist. Nur wenn sogar das Beispielprogramm nicht funktioniert dann weiß ich auch nicht weiter.

Trotzdem danke für den Hinweis. Hast du vvielleicht noch eine Idee oder eine funktionierende Lösung? Alle anderen Hinweise sind natürlich auch willkommen.

[Bernhard Geyer]

Kann es sein das es mit 64-Bit zu tun hat?
Also unter Win7 und älter hattest du 32-Bit Windows, jetzt ein 64-Bit Windows.

[Dalai]

Genau in die Richtung denke ich auch, wenn ich irgendwas mit Registry sehe und darin kein Hinweis auf die entsprechenden Flags auftaucht. Dazu kommt noch, dass der Server ab 2008 R2 AFAIK immer 64 Bit ist. Das könnte also sehr gut sein.

Übrigens sind in dem Code ein paar Speicherlecks drin, denn da wird z.B. im Destruktor das Objekt FFileStream nicht wieder weggeräumt. Und noch eine andere Sache ist mir aufgefallen: Warum wird in GetPreviewHandlerCLSID() immer wieder die CLSID geschrieben statt die als Konstante zu deklarieren und diese zu benutzen? Sowas ist anfällig für Tippfehler etc, verstößt gegen DRY usw.

Zum Debuggen würde ich wahrscheinlich ein paar OutputDebugString() an den richtigen Stellen reinpacken, wenn das im normalen Debugger nicht möglich oder sinnvoll zu machen ist.

MfG Dalai

[Aviator]

Zitat von Bernhard Geyer:

Kann es sein das es mit 64-Bit zu tun hat?
Also unter Win7 und älter hattest du 32-Bit Windows, jetzt ein 64-Bit Windows.

Nein leider auch nicht. War vorher auch immer schon 64-bit und es hatte alles funktioniert.

[Dalai]

Zitat von Aviator:

War vorher auch immer schon 64-bit und es hatte alles funktioniert.

Das sagt leider überhaupt nichts aus. Hast du denn mal geschaut, was in den jeweiligen Registry-Zweigen zu finden ist, sowohl 32 als auch 64 Bit? Vielleicht ist auf dem einen System der Handler nur für 64 Bit registriert, auf dem anderen aber für beide.

MfG Dalai

[Aviator]

Hallo Dalai,
habe jetzt einmal alle mir bekannten Registry Zweige durchsucht und ein Windows 8 bei dem es nicht funktioniert mit einem Windows 7 System bei dem die Vorschau startet verglichen. Mir sind keine Unterschiede aufgefallen. Beide Systeme sind 64-bit. Es ist sogar eher so herum, dass die PreviewHandler alle in den Wow6432Node auffindbar sind, als direkt im CLSID Zweig. Mein Programm ist nicht speziell für 64-bit kompiliert, sondern läuft als 32-bit Anwendung. Wäre es möglich, dass Windows 8 hier anders reagiert als Windows 7?

Die Hinweise auf die mehrfache Einträge von CLSID werde ich in meiner Kopie des Codes verbessern und daraus eine Konstante machen. Von der Freigabe des FileStreams wurde mir damals von Jeanicke bereits abgeraten, da der TStreamAdapter mit soOwned erzeugt wird. Also hatte ich das entfernt. Siehe hierzu den Beitrag im anderen Thread. Bisher hatte ich auch trotz ReportMemoryLeaksOnShutdown := True; keine Fehler mehr beim Beenden des Programms erhalten.

Ich möchte an dieser Stelle schon einmal ein Dankeschön für die vielen Beiträge einwerfen. Das Problem ist aber leider immer noch nicht gelöst.

[Dalai]

Zitat von Aviator:

Es ist sogar eher so herum, dass die PreviewHandler alle in den Wow6432Node auffindbar sind, als direkt im CLSID Zweig.

Du meinst HKEY_CLASSES_ROOT-Zweig? Vorsicht, der ist - jedenfalls bestimmte Unterzweige davon - ebenfalls der Redirection unterworfen! HKEY_CLASSES_ROOT ist die Summe aus HKEY_LOCAL_MACHINE\Software\Classes und HKEY_CURRENT_USER\Software\Classes - und ersterer wird umgeleitet (auf einem x64 System).

Zitat:

Wäre es möglich, dass Windows 8 hier anders reagiert als Windows 7?

Denkbar. Aber das wirst du debuggen müssen; wenn es nicht anders geht, dann eben mit OutputDebugString, wie ich bereits ansprach.

Zitat:

Von der Freigabe des FileStreams wurde mir damals von Jeanicke bereits abgeraten, da der TStreamAdapter mit soOwned erzeugt wird. Also hatte ich das entfernt. Siehe hierzu den Beitrag im anderen Thread.

Ah, OK.

Zitat:

Bisher hatte ich auch trotz ReportMemoryLeaksOnShutdown := True; keine Fehler mehr beim Beenden des Programms erhalten.

Nun, dessen Nutzen ist auch (stark) begrenzt, wie ich selbst erfahren habe. IIRC werden alle Sachen, die Nicht-Delphi-Objekte sind, nicht gemeldet, also direkte WinAPI-Aufrufe usw.

MfG Dalai

[Aviator]

Hallo zusammen,
ich habe gerade noch einmal das Testprogramm von GitHub kompiliert und dieses mal die Zielplattform auf 64-bit umgestellt. Und siehe da es funktioniert tatsächlich unter Windows 8. Also scheint es wirklich eine 64-bit Inkompatibilität in Sachen PDF-Preview mit einem 32-bit Programm zu geben. Der Tipp mit der Registry und dem nicht registrierten Handler für 32-bit scheint dann auch in die richtige Richtung zu gehen. Jetzt ist nur die Frage, ob ich mein Programm so einfach auf 64-bit portiert bekomme, da ich keine Ahnung habe, was man hierfür alles beachten muss. Bisher liefen alle meine Programme als 32-bit Programm ohne Probleme. Und ein weiterer Punkt ist, dass die Anwendung in einer Netzwerkumgebung gestartet und nicht installiert wird. Somit starten alle Benutzer die 32-bit Version. Ich kann aber auch nicht einfach eine 64-bit Version kompilieren und diese reinstellen. Oder kann man unter 32-bit auch eine 64-bit Software einfach so laufen lassen? Ich glaube es ja nicht.

Der einfachere Weg wäre der, dass ich es irgendwie schaffe, den PreviewHandler auf einem Windows 8 System für 32-bit nachzuregistrieren. Ist das irgendwie möglich? Damit wäre mir sehr geholfen.