Seltsamer Fehler beim schließen

[himitsu]

Eine MessageBox noch zwischen die beiden Fenster und auch mal die Reihenfolge (der Free) tauschen
und schon weißt du bei welchem Form es hängt.

Das kann nun ein Code im OnDestroy sein oder eine der Komponenten.


PS: hier muß man aufpassen, denn wenn die Fenster schon vorher freigegeben wurden, dann steht in der Variable eine falsche Referenz, da normalerweise keiner diese Variablen freigibt, da sie keiner mehr kennt ... drum hatte ich auch das FreeAndNil verwendet, damit danach die Variable auch nil ist, denn dann knallt es "schöner", falls nochmal wer auf diese Variable zugreift.

[Satyr]

Dann wird mein Fehler irgendwo in Form1 sein. Im Destroy steht nichts drin. Dann gehe ich morgen jede Komponente einzeln durch.

Vielen Dank Euch für die Hilfe. Ich wusste nicht wo ansetzen und wie schon garnicht. Danke .

[pelzig]

Ein ähnliches Problem hatte ich - schon länger her - auch mal und habe dann ewig rumgesucht und bei den potentiell Verdächtigen eine MessageBox-Meldung reingedengelt.

Gefunden habe ich dadurch den Fehler nicht, sondern eher durch Zufall: Im Hauptformular die Reihenfolge der eingebundenen Komponenten-Units ändern schuf Abhilfe

Testen musste ich die Echse aber (quasi nach jeder Buchstabenänderung im Quelltext) in einer VirtualBox (mit XP darin), in der kein Delphi installiert war (da mein Entwicklungsrechner-OS natürlich Delphi kannte).

MfG

[himitsu]

Zitat von pelzig:

Ein ähnliches Problem hatte ich auch mal ...

Dein Problem klingt zuerst mal nach einer falschen Initialisierungs-/Finalisierungsreihenfolge, welche vorallem dadurch entsteht, wenn man unnötige/ungünstige Units in Implementation, anstatt im Interface einbindet, wobei die Initialisierungs-/Finalisierungsreihenfolge sich zufällig ändern kann.

Bzw. nicht oder falsch deregistrierte Komponenten/Funktionen welche vorher registriert wurden.

[pelzig]

Ja und nun was denn? Vielleicht haz der TE genau dieses Problem?

MfG

[himitsu]

Dann ist aber das wahllose Rumpfuschen an der Unitliste der "falsche" Weg, denn so werden nur die Symptome behoben, aber nicht die Ursache,
womit das Problem also irgendwann unverhofft wieder auftauchen könnte.

Das Einzige, wo diese Art der Lösung nötig ist, wären Compilerfehler (die berühmten "internal error"), wenn schnell eine Lösung benötigt wird, oder wenn man mit einem Bugfix nicht mehr zu rechnen braucht.


Da kann man auch gleich die Hardcorelösung benutzen.
- ich kann mein Programm nicht beenden, ohne daß es zu Exceptions kommt
- na dann schieße ich das Programm einfach hart ab und weg ist das Problem

[jaenicke]

Zitat von Satyr:

Dann wird mein Fehler irgendwo in Form1 sein. Im Destroy steht nichts drin.

Das deutet eher darauf hin, dass du die Variable Form1 irgendwo veränderst oder selbst irgendwo freigibst.

Zitat von Satyr:

Interessant, ExitProcess(0) geht, Halt(0) nicht.

Halt bedeutet:
Mit voller Fahrt gegen den Baum fahren um anzuhalten.
Bist du sicher, dass du das möchtest? Dass es dabei auch knallen kann, dürfte klar sein.

Zitat von Satyr:

Gibt es noch eine andere Möglichkeit das finalisieren durchzusteppen, als wie gestern Abend? Zum Beispiel nur das was in Form1 passiert?

Debug-DCUs in den Projektoptionen aktivieren.

[Satyr]

Also wenn ich per grep search nach Form1 suche, kommt nichts wo ich das sonst beende oder freigebe.

Ich möchte Halt() nicht dauerhaft verwenden. Ich wollte nur mal testen was die Stelle mit dem Fehler nicht durchgeht, Halt() oder ExitProcess(). Ich habe (wieder Google) gelesen das Halt() trotzdem finalized und ExitProcess() nicht. Da bei Halt() der Fehler bleibt, ist mir so recht klar wo er ist. Nur wie ich weitersuche noch nicht so ganz. Was Debug-DCU's sind muss ich mir noch ergooglen *g*.