Delphi nicht fähig COM zu verwalten?

[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

[Furtbichler]

In VC(++) geschriebene Programme scheinen diese Meldung zu generieren.

Das msdmo.dll diesen Fehler generiert, glaube ich nicht, eher d3d8.dll, wegen der ähnlichen Adresse (0x68xxxx')

Du kannst nach der Meldung googeln, um näheres in Erfahrung zu bringen. Es gibt auch Tools, um den Bösewicht zumindest ausfindig zu machen.

Theoretisch denkbar wäre es auch, das es sich nicht um eine Exception handelt, bei Delphi anhält, sondern um einen Breakpoint, da die DLL im Debugmodus kompiliert wurde. Ist mir auch schon ein paar mal begegnet. Zumindest glaube ich das