Strg+C von Dateien Fehler: Invalid floating point operation.

[danisahne]

Okay, dass habe ich soweit verstanden und auch schon ausprobiert - es funzt.

Aber was macht dieses Programm ShellExView eigentlich? Wird hier auch die Registry geändert. Ich habe nämlich mal meinen Eintrag in der Registry angeschaut, dort hat sich dach der Deaktivierung soweit ich sehen konnte nichts geändert...

Die Frage eigentlich, wo werden die Einstellungen aktiviert oder deaktiviert letztendlich abgespeichert?

Viele Grüße

danisahne

[icfu]

Ich habe Dir alle nötigen Infos gegeben, den Rest findest Du auf der Homepage. Wenn Du keine Änderung in der Registry siehst, hast Du nicht richtig geguckt. Mach Dich mit Sysinternals Regmon vertraut, wenn Du Änderungen mitloggen und verstehen willst. Das führt ein wenig zu weit hier...

Da Du zudem keine Lust hast, selber Informationen hier zu posten – welche Extension der Übeltäter war hast Du nun immer noch nicht mitgeteilt – war's das meinerseits. Dein Problem ist gelöst, also sei's drum.

Icfu

[HolgerK]

Irgendwie werde ich den Eindruck nicht los, das hier ein Borland-Delphi <-> M$-C Streit auf dem Rücken des Anwenders ausgetragen wird.

Typischerweise sind in einer C-Umgebung die FloatingPointExceptions maskiert, während in einer Borland-Umgebung die FPE Maskierung etwas restriktiver ausfällt.

Da Shellextensions allerdings für den M$-Explorer (der definitiv keine Borland Umgebung ist) geschrieben sind, wäre es vielleicht angebracht, dass TC - wenn er denn von diesen Gebrauch macht - eine Umgebung schafft in der die Shellextensions ähnlich wie im Explorer ausgeführt werden können.

Es ist zwar ein hehres Ziel, allen Shellextension-Programmierer nahezulegen ihren Code auch im TC lauffähig zu gestalten, allerdings zweifel ich so ein bisschen an dem Erfolg.

2Christian
Wäre es nicht eine Alternative, um den Code - der z.B. das Kontextmenu aufruft - herum folgende Zeilen (C-Beispiel) zu plazieren:

Code: Select all

// aktuelles FPU control word abfragen:
	unsigned int uiSaveControlWord = _control87(0, 0);

// die floating point exceptions maskieren:
	_control87(MCW_EM, MCW_EM);

// hier wird das Kontextmenue aufgebaut und evtl. ein Eintrag aufgerufen:
	...
	...

// Jetzt noch eine eventuell aufgetretene Fehlerbedingung zurücksetzten:
	_clear87();

// den vorherigen Zustand des FPU- control words restaurieren: 
	_control87(uiSaveControlWord, MCW_EM);

Auf die gleiche Art könnte man auch den Zugriff auf Shell.. InfoTip-, Icon-, Drop-, PropertySheet-, ThumNail- ..Handler umrahmen, und damit einige der lästigen "Floating Point Invalid Operation Exceptions" vermeiden.

Mit freundlichem Gruß,
Holger

[ghisler(Author)]

2HolgerK
Das kann ich schon machen, aber nützen wird es wohl kaum etwas - wenn ich die FPU-Exceptions wieder einschalte, ist das Kontextmenü ja noch aktiv, oder? Selbst wenn ich sie erst nach Ende von TrackPopupMenu wieder anschalte, können sie von Delphi während dem Repaint in den Dateilisten von Delphi wieder eingeschaltet werden...

Andere Idee: Gelten die Einstellungen für Floating Point Exceptions eigentlich global für das Programm, oder separat pro Thread? Falls separat, könnte ich das Kontextmenü in einem eigenen Thread erzeugen - frag sich nur, wann ich den dann beenden kann...

[HolgerK]

Ob die FPU Einstellungen Thread lokal sind kann ich nicht leider nicht garantieren. Da müsste ich jetzt auch erstmal ein Testprogram aufsetzen.
Es würde allerdings nur dann zu Fehlern kommen, wenn in anderen Threads das Controlword asynchron umgesetzt würde und gelichzeitig im momentanen Thread eine Exceptionbedingung auftritt, oder Exceptions in anderer Threads erwartet würden und auf einmal nicht mehr auftreten würden.

Ich würde eher darauf tippen, dass die FPU Einstellungen nur bei einem Prozesswechsel gesichert werden.

Das Umschalten bringt trotzdem einiges an Sicherheit, wenn es das TrackPopupMenu und ein eventuelles InvokeCommand umschließen würde.

Damit wäre zumindestens das Laden (passiert bereits wenn die Menueinträge aufgesammelt werden) der Shellextensions abgesichert. Falls eine Exception nur im Initialisierungscode einer DLL auftritt, dann wäre der Fehler an dieser Stelle schon mal abgefangen.

Es wird zudem immer nur ein Eintrag aus dem Kontextmenu vom Anwender aufgerufen, aber immer alle Shellextensons geladen. Und wenn dann wirklich beim Invoke einer schlecht programmierten Shellextension ein nicht modaler Dialog von der Shellextension aufgemacht wird, in dem ein Fehler auftritt, dann ist er zumindestens eindeutig einem bestimmten Menueintrag/Hersteller zugeordnet.

Das würde dem Anwender sofort einen Hinweis geben, an wen er sich in einem solchen Fall wenden kann, bzw. die Entscheidungsmöglichkeit bieten auf diesen Eintrag nicht mehr zuzugreifen.

Momentan ist das ein Rätselraten und temporäres Deaktivieren/Ausprobieren von Shellextensions, das für einen nicht Computerexperten eher frustrierendes Vodoo ist.

Mit freundlichem Gruß,
Holger

[ghisler(Author)]

Bisher waren die Floating Point Exceptions eigentlich nie der Grund für fehlerhafte Shellextensions, deshalb habe ich auch keinen Code dagegen im TC. Wieso sollte auch eine sauber programmierte Software Fehler bei Floatingpointoperationen aufweisen?

Deshalb wäre es auch wichtig, den Autor der Extension zu kontaktieren. Ich werde trotzdem mal vorsehen, die Exceptions vor dem Erzeugen des Kontextmenüs zu deaktivieren...

[HolgerK]

Der Fehler kann auch durch die Benutzung von Fremd-DLL's entstehen, die der Programmierer der Shellextension gar nicht ändern kann.

Gruß,
Holger

PS: meine eigenen Shellextensions habe ich sogar mit dem TC als Testprogramm entwickelt.
Ist in diesem Fall wesentlich einfacher einzusetzen, als mit mehreren Explorer-Instanzen zu arbeiten, die dann der Reihe nach wieder abgeschossen werden müssen, damit man die DLL neu bauen kann.
Wozu der TC nicht alles gut ist~