Absturz in Verbindung mit TOpenDialog

[Codehunter]

Moin!

Ich habe einen Kundenrechner (W10x64), bei dem mein Programm häufig aber nicht immer crasht, wenn TOpenDialg geöffnet wird. Es könnte etwas mit diesem älteren Thread zu tun haben, für den es damals aber auch keine Lösung gab. Ich vermute irgendeine Shellextension, Virenscanner, Iconcache o.ä. als Ursache.

Zum Einkreisen des Fehlers wollte ich TOpenDialog.Options + [ofOldStyleDialog] nutzen, da hier viele Shellextensions außen vor gewesen wären. Doch wie mir auffällt, ignoriert Delphi ofOldStyleDialog und zeigt das Öffnen-Fenster immer im neuen Style an. Ist das ein Bug oder mache ich da was verkehrt?

Grüße
Cody

[Redeemer]

Keine Lösung, aber: Ich glaube, ofOldStyleDialog geht nur bei XP, denn die Delphi-Hooks für den TOpenImageDialog gehen auch nicht mehr in neueren Versionen.

[Codehunter]

Ich habe zur Sekunde die Lösung selbst gefunden:

Delphi-Quellcode:

UseLatestCommonDialogs:= FALSE;
if OpenDialog1.Execute then begin
  // ...
end;

[Redeemer]

Richtig, das fiel mit gerade nicht ein. Das macht auch, dass die Bild-Öffnen-Dialoge unter 7 funktionieren, was praktisch sein kann, wenn man eine Vorschau für Dateien implementieren möchte, die Windows nicht kennt.

[Uwe Raabe]

Zitat von Codehunter:

UseLatestCommonDialogs:= FALSE;

Alternativ kannst du auch einen der Events OnClose , OnShow oder OnIncludeItem verdrahten, dann werden auch die alten Dialoge verwendet.

[Bernhard Geyer]

Was sagt den die Windows-Ereignisanzeige? Bei mir waren hier DLLs aufgelistet die sich als ShellExtension rein gehängt hatten.

[Codehunter]

Ich warte noch auf Kundenrückmeldung der letzten Änderungen. Bei der nächsten Fernwartung schaue ich nach. Auch wenn die Frage im konkreten Fall noch ungeklärt ist: Es kann doch nicht sein, dass Shellextensions seit gut 10 Jahren Delphi-Anwendungen niederknüppeln und sich Emba und MS gegenseitig den schwarzen Peter zu schieben, eine Lösung bisher nicht in Sicht ist und wir uns mit Workarounds wie den ganz alten, aus Windows-95-Zeiten stammenden OldStyle-Dialogen begnügen müssen.

[Bernhard Geyer]

Zitat von Codehunter:

Ich warte noch auf Kundenrückmeldung der letzten Änderungen. Bei der nächsten Fernwartung schaue ich nach. Auch wenn die Frage im konkreten Fall noch ungeklärt ist: Es kann doch nicht sein, dass Shellextensions seit gut 10 Jahren Delphi-Anwendungen niederknüppeln und sich Emba und MS gegenseitig den schwarzen Peter zu schieben, eine Lösung bisher nicht in Sicht ist und wir uns mit Workarounds wie den ganz alten, aus Windows-95-Zeiten stammenden OldStyle-Dialogen begnügen müssen.

Es ist nich Emba, es ist nicht MS schuld und dies schieben sich nicht gegenseitig den schwarzen Peter zu.
Wenn eine DLL im Adressraum deiner Anwendung geladen wird und eine Absturz vollführt, dann ist diese DLL schuld bzw. dann hat der Hersteller der DLL hier nacharbeit zu leisten.
Falls es dem Hersteller egal ist, so wäre eine Idee das Laden der DLL zu verhindern (z.B. durch einen Hook auf die LoadLibrary-WinAPI-Funktion).

[Codehunter]

Zitat von Bernhard Geyer:

Es ist nich Emba, es ist nicht MS schuld und dies schieben sich nicht gegenseitig den schwarzen Peter zu.
Wenn eine DLL im Adressraum deiner Anwendung geladen wird und eine Absturz vollführt, dann ist diese DLL schuld bzw. dann hat der Hersteller der DLL hier nacharbeit zu leisten.
Falls es dem Hersteller egal ist, so wäre eine Idee das Laden der DLL zu verhindern (z.B. durch einen Hook auf die LoadLibrary-WinAPI-Funktion).

Genau das wollte ich eigentlich damit ausdrücken, dass es nicht sein kann dass sich diese zwei den schwarzen Peter zuschieben. Allerdings so ganz aus der Verantwortung will ich Emba auch nicht entlassen. Denn TOpenDialog bildet einen Systemdialog ab, der auch in anderen (Non-Delphi-) Programmen zum Einsatz kommt und dort nicht zu Abstürzen führt.

Genau dann hat man nämlich die Situation, dass die Anwender nur die Wirkung und nicht die Ursache sehen. Mein Programm stürzt ab, während Programm xyz problemlos mit der selben Shellextension läuft. Also muss der (Anwender-) Logik zufolge mein Programm Schuld sein und nicht die Shellextension.

[Der schöne Günther]

Dumme Idee: Delphi-Prozesse sind ja dergestalt oft "anders" als wie bspw. die FPU-Exception-Masken gesetzt sind. Ob das damit zu tun haben könnte?