Delphi nicht fähig COM zu verwalten?

[EWeiss]

Ich kann machen was ich will.
Wenn ich während des Rendern einer Visualisierung ein mit Win32API, Menü aufrufe
um das nächste Preset zu starten meldet mir der Compiler einen Schweren Ausnahme Fehler.

Das passiert aber nur unter NonVCL

Addiere ich die Presets in ein TStringGrid also beim Initialisieren des Plugin .. Einmalig
und ändere dann die Presets aus dem StringGrid gibt es keinerlei problem.

Wie kann ich den Fehler der "NUR" in der Ide nicht aber
als compilierte Exe auftritt abfangen?

Die selbe Library geschrieben in Delphi in verwendung mit folgenden Sprachen
VB_NET, C#_NET, VB6, PowerBAsic, C++ treten diese Probleme nicht auf.

Debug: Auszug

Zitat:

Thread-Ende: Thread-ID: 4320. Prozess Soundmachine.exe (220)
Modul laden: AlbumArt3D.DLL. Ohne Debug-Infos. Basisadresse: $0F300000. Prozess Soundmachine.exe (220)
Modul laden: d3dx9_28.dll. Ohne Debug-Infos. Basisadresse: $04900000. Prozess Soundmachine.exe (220)
Modul laden: d3d9.dll. Ohne Debug-Infos. Basisadresse: $6B2E0000. Prozess Soundmachine.exe (220)
Modul laden: d3d8thk.dll. Ohne Debug-Infos. Basisadresse: $6BEE0000. Prozess Soundmachine.exe (220)
Modul laden: Tolerance.DLL. Ohne Debug-Infos. Basisadresse: $681F0000. Prozess Soundmachine.exe (220)
Modul laden: CRYPTSP.dll. Ohne Debug-Infos. Basisadresse: $73F20000. Prozess Soundmachine.exe (220)
Modul laden: RSAENH.dll. Ohne Debug-Infos. Basisadresse: $73E30000. Prozess Soundmachine.exe (220)
Modul laden: RpcRtRemote.dll. Ohne Debug-Infos. Basisadresse: $73E20000. Prozess Soundmachine.exe (220)
Thread-Start: Thread-ID: 2896. Prozess Soundmachine.exe (220)
Modul laden: Bubbles.DLL. Ohne Debug-Infos. Basisadresse: $04D00000. Prozess Soundmachine.exe (220)
Modul laden: d3dx9_29.dll. Ohne Debug-Infos. Basisadresse: $04EF0000. Prozess Soundmachine.exe (220)
Modul laden: clarity.DLL. Ohne Debug-Infos. Basisadresse: $05340000. Prozess Soundmachine.exe (220)
Modul laden: d3dx9_31.dll. Ohne Debug-Infos. Basisadresse: $054C0000. Prozess Soundmachine.exe (220)
Modul laden: MEDIAPLAYER_10.DLL. Ohne Debug-Infos. Basisadresse: $05250000. Prozess Soundmachine.exe (220)
Modul laden: d3d8.dll. Ohne Debug-Infos. Basisadresse: $680E0000. Prozess Soundmachine.exe (220)
Modul laden: MEDIAPLAYER_9.DLL. Ohne Debug-Infos. Basisadresse: $05730000. Prozess Soundmachine.exe (220)
Modul laden: metalArcs.DLL. Ohne Debug-Infos. Basisadresse: $05CB0000. Prozess Soundmachine.exe (220)
Modul laden: PULSING COLORS.DLL. Ohne Debug-Infos. Basisadresse: $04DA0000. Prozess Soundmachine.exe (220)
Modul laden: RibbonsVis.DLL. Ohne Debug-Infos. Basisadresse: $05B00000. Prozess Soundmachine.exe (220)
Modul laden: T3.DLL. Ohne Debug-Infos. Basisadresse: $05E50000. Prozess Soundmachine.exe (220)
Modul laden: SHFOLDER.dll. Ohne Debug-Infos. Basisadresse: $68D70000. Prozess Soundmachine.exe (220)
Modul laden: ThreeDBars.DLL. Ohne Debug-Infos. Basisadresse: $05B30000. Prozess Soundmachine.exe (220)
Modul laden: TRILOGY I.DLL. Ohne Debug-Infos. Basisadresse: $05F20000. Prozess Soundmachine.exe (220)
Modul laden: TRILOGY II.DLL. Ohne Debug-Infos. Basisadresse: $05F50000. Prozess Soundmachine.exe (220)
Modul laden: TRILOGY III.DLL. Ohne Debug-Infos. Basisadresse: $05F80000. Prozess Soundmachine.exe (220)
Modul laden: upCuber.DLL. Ohne Debug-Infos. Basisadresse: $06C70000. Prozess Soundmachine.exe (220)
Modul laden: VISUALIZATION-ONE.DLL. Ohne Debug-Infos. Basisadresse: $05FB0000. Prozess Soundmachine.exe (220)
Thread-Start: Thread-ID: 4272. Prozess Soundmachine.exe (220)
Thread-Start: Thread-ID: 3240. Prozess Soundmachine.exe (220)
Modul laden: ole32.dll. Ohne Debug-Infos. Basisadresse: $072A0000. Prozess Soundmachine.exe (220)
Modul entladen: ole32.dll. Prozess Soundmachine.exe (220)
Modul laden: dsdmo.dll. Ohne Debug-Infos. Basisadresse: $67E70000. Prozess Soundmachine.exe (220)
Modul laden: msdmo.dll. Ohne Debug-Infos. Basisadresse: $6BBF0000. Prozess Soundmachine.exe (220)
Thread-Start: Thread-ID: 4432. Prozess Soundmachine.exe (220)
Thread-Ende: Thread-ID: 4272. Prozess Soundmachine.exe (220)
Debug-Ausgabe: HEAP[Soundmachine.exe]: Prozess Soundmachine.exe (220)
Debug-Ausgabe:
HEAP: Free Heap block 68c0040 modified at 68cca9c after it was freed

Bei Free Heap block hängt er.
Läßt sich aber danach weiter.. fortführen.
Nicht zu fixen ?

EDIT:
Das problem mit dem Rendern konnte ich abfangen in dem ich post anstelle von SendMessage verwende.

gruss

[hoika]

Hallo,

Zitat:

Wie kann ich den Fehler der "NUR" in der Ide nicht aber
als compilierte Exe auftritt abfangen?

Hm,
verstanden habe ich die Frage nicht, einfach zu wenig Informationen.

Aber wenn der Fehler in der IDE auftritt und nivht in der Exe,
liegt es vielleicht dran, dass du ihn in der Exe per

try except

abfängst?


Heiko

[jaenicke]

Zeig am besten einfach einmal einen Screenshot der Meldung in Delphi und die entsprechende Stelle des Quelltextes.

[EWeiss]

Zitat von jaenicke:

Zeig am besten einfach einmal einen Screenshot der Meldung in Delphi und die entsprechende Stelle des Quelltextes.

Habe ich doch

Zitat:

Debug-Ausgabe: HEAP[Soundmachine.exe]: Prozess Soundmachine.exe (220)
Debug-Ausgabe:
HEAP: Free Heap block 68c0040 modified at 68cca9c after it was freed

Scheinbar produziert msdmo.dll diesen Fehler wenn das so ist werde ich ihn wohl nicht beheben können.

Zitat:

und die entsprechende Stelle des Quelltextes

Die gibt es nicht, geht nur das AMS Fenster auf das war's dann.

Das problem mit dem Rendern habe ich gelößt durch PostMessage..
Anscheinend vertragen die WMP Plugins keinerlei Unterbrechung im Render Thread

Zitat:

Aber wenn der Fehler in der IDE auftritt und nivht in der Exe,
liegt es vielleicht dran, dass du ihn in der Exe per

try except

abfängst?

Nein fange ich nicht ab geht auch nicht da der RenderThread außerhalb meiner Anwendung ist.


gruss

[jaenicke]

Zitat von EWeiss:

Habe ich doch

Nein, ich meinte wie die Meldung in Delphi aussieht. Ist das wie eine Exception mit Fortsetzen, Anhalten, ...? Oder nur im Ereignislog?

Das "modified after it was freed" sieht mir ein wenig wie FastMM aus, kann es sein, dass du das drin hast und zwar so eingestellt, dass es das nur in Delphi melden soll?

[EWeiss]

Zitat von jaenicke:

Zitat von EWeiss:

Habe ich doch

Nein, ich meinte wie die Meldung in Delphi aussieht. Ist das wie eine Exception mit Fortsetzen, Anhalten, ...? Oder nur im Ereignislog?

Das "modified after it was freed" sieht mir ein wenig wie FastMM aus, kann es sein, dass du das drin hast un zwar so eingestellt, dass es das nur in Delphi melden soll?

Es kommt keinerlei Meldung..
Die Anwendung wird angehalten dann geht das Debug(ASM) Fenster auf.
Unten im Debuger-Logfenster steht dann der Fehler mit dem Heap

Nach dem klick oben im Menü (grüner Pfeil) läuft die Anwendung ohne Fehler weiter
solange bis ich halt das nächste Preset starte.

Es kommt kein Dialog oder sonstiges.

PS:
Verwende kein FastMM weder in der DLL noch in der Anwendung.

gruss

[Furtbichler]

Das ist vielleicht eine Exception im COM-Objekt selbst. Da der Debugger aktiv ist und er bei Exceptions anhalten soll, macht er das auch. Das macht er selbst dann, wenn die Exception im COM-Objekt selbst abgefangen wird.

Ist zumindest bei mir so und eigentlich nicht Unfähigkeit, sondern gewolltes Verhalten.

[EWeiss]

Zitat:

Das ist vielleicht eine Exception im COM-Objekt selbst.

Selbst wenn es der Fall wäre müßte in Delphi trotzdem ein Exception geworfen werden.
Welchen Sinn macht es denn dann safecall anstelle von stdcall zu verwenden?

Hier sollte also ein HRESULT zurückgegeben werden aus dem Delphi dann sein Exception bastelt.
Aber wie gesagt da kommt nix bis auf die Meldung mit dem Heap

[Bernhard Geyer]

Zitat von EWeiss:

Zitat:

Das ist vielleicht eine Exception im COM-Objekt selbst.

Selbst wenn es der Fall wäre müßte in Delphi trotzdem ein Exception geworfen werden.
Welchen Sinn macht es denn dann safecall anstelle von stdcall zu verwenden?

Hier sollte also ein HRESULT zurückgegeben werden aus dem Delphi dann sein Exception bastelt.
Aber wie gesagt da kommt nix bis auf die Meldung mit dem Heap

Delphi kann aber auch nur eine Exception daraus basteln wenn die Entwickler der COM-Komponenten es richtig gemacht haben da das möglich ist. Und du kannst mir glauben: Hier gibt es genügend (auch von MS oder anderen großen Firmen) bei denen man bald mehr Zeit mit der Umschiffung von Fehlern der COM-KOmponenten verbringt als mit der eigentlichen Verwendung.

[EWeiss]

Zitat:

Und du kannst mir glauben:

Glaube ich dir gern ..
Ich werde dann wohl nichts anderes machen können als diesen Fehler zu ignorieren.
Bleibt mir wohl in diesen speziellen Fall nichts anderes übrig.

Dank dir!

gruss