Delphi nicht fähig COM zu verwalten?

[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.