Grund für Runtime Error 216 finden

[Dejan Vu]

Stimmt, mit FastMM sollte man anfangen.

[himitsu]

Benutzt du Packages?

Sind bei dir Units möglichst immer im Interface eingebunden (uses) oder auch zu oft grundlos in Implementation?


Wenn man da z.B. Objektreferenzen ungünstig verwaltet und dann z.B. noch nach dem freigeben der Unit oder eines Packages benutzt, dann dann das schnell mal knallen.
Beim "externen"/großen FastMM kann man einige FullDebug-Features einbinden, wo man auch doppelte Freigaben und (schreibende) Speicherzugriffe nach dem Freigeben erkennen lassen kann.

[MartinK]

Danke euch zunächst schon mal

na dann werde ich mal mit FastMM starten, denn beim debuggen merke ich nur "das" es "knallt" und nicht wieseo

[teebee]

Wenn Du mit Arrays arbeitest, kann es auch sinnvoll sein, zu Debugging-Zwecken mal die Bereichsüberprüfung einzuschalten. Array-Grenzen zu verletzen kann zu viel späteren Zeitpunkten für Probleme sorgen.

[MartinK]

@Teebee: DAs war "DER" Tipp.

Ich hatte 2 Stellen "Schreibfehler" im Sourcecode die mir früher nie aufgefallen sind.
Durch die bereichsüberprüfung fielen diese bereits beim Programmstart auf ... wurden korrigiert
und damit war ich auch den RT Error 216 los.

Dickes danke dafür !
Die Bereichsprüfung ist ab sofort stanbdardmässig auf "on"

[teebee]

Zitat von MartinK:

Die Bereichsprüfung ist ab sofort stanbdardmässig auf "on"

Würde ich beim Release rausnehmen, macht die Anwendung langsamer (muss nicht spürbar sein) und größer.

[Luckie]

RT 216 ist eine Access Violation. Also in der Regel ein Zugriff auf einen ungültigen Speicherbereich. Kann bei dynamischen Arrays durch eine Unachtsamkeit schnell passieren.