Seltsamer Fehler beim schließen

[Sir Rufo]

Zitat von Satyr:

Ich habs nur für den close benutzt. Im Grunde nur zur reinen Übersichtlichkeit, für mich war der Code so strukturierter zu lesen.

Dann solltest du korrekterweise Self.Close nehmen, denn Self (in einer Methode) ist immer der Verweis auf die aktuelle Instanz.

Im Gegensatz dazu ist Form1 der Verweis auf eine Instanz, die dort irgendwann mal von wem auch immer reingeschrieben wurde. Du kannst dir aber niemals sicher sein, dass das auch der Verweis auf die aktuelle Instanz ist, bei Self ist das per Definition immer so.

[Satyr]

Danke für die Hinweise und Tipps .

Also eine MessageBox nach Run wird beim Beenden von dem Programm angezeigt. Nun weiß ich aber nicht genau wo ich die Formulare per Hand freigeben soll.

Es könnte trotzdem sein das ich hier irgendwo etwas falsch mache. Ich habe das für eine SplashScreen ein wenig umgebaut, die Anleitung fand ich damals per Google. Hier der Code:

Delphi-Quellcode:

program Conceptor;

uses
  madExcept,
  madLinkDisAsm,
  madListHardware,
  madListProcesses,
  madListModules,
  Forms,
  sysUtils,
  Unit1 in 'Unit1.pas' {Form1},
  Unit2 in 'Unit2.pas' {SplashScreen},
  Unit3 in 'Unit3.pas' {notepad},
  func in 'func.pas';

{$R *.res}

begin


Application.Initialize;
Application.Title := 'Conepter';

SplashScreen := TSplashScreen.Create(nil);
SplashScreen.Show;

application.ProcessMessages;
Sleep(1000);


  Application.CreateForm(TForm1, Form1);
  Application.CreateForm(Tnotepad, notepad);


  Application.Run;
end.

[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

[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