Seltsamer Fehler beim schließen

[himitsu]

Application.Title := 'Conepter'; C?

Du könntest nach dem Application.Run mal ein FreeAndNil(Application) reinmachen und danach noch eine MessageBox.
Oder erstmal nur FreeAndNil(Form1); FreeAndNil(notepad); nach dem Run.

Bzw. über Screen.CustomForms alle Fenster auflisten und Diese freigeben.


Als allererste Unit in der DPR eine Unit aufnehmen, die nur Windows einbindet (im Interface) und in Finalization eine MessageBox anzeigt.


Wer gibt eigentlich den SplashScreen wieder frei?

[Satyr]

Hm! Also das hier:

Delphi-Quellcode:

  Application.Run;

  FreeAndNil(Form1); FreeAndNil(notepad);
  Application.MessageBox('test', 'Test');

zeigt die Message an wenn ich das in Delphi rennen lasse, nicht aber auf dem Rechner mit Fehler. Da kommt nur wieder der Fehler und das wars.

Wenn ich dann die Formulare einzeln durchgehe, liegt der Fehler dann im Formular?

Edit: Den SplashScreen gebe ich in Form1 frei.

[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

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