Problem mit Stringlists (.free)

[florpp]

Ich bin zurzeit bei einem Programm dabei ein wenig mit Stringlists zu hantieren.

Delphi-Quellcode:

...

var
  Form1: TForm1;
  sc   : TStringlist;
  tx   : TStringlist;
  ms   : TStringlist;

...

procedure TForm1.FormShow(Sender: TObject);
begin
  sc := TStringlist.Create;
  tx := TStringlist.Create;
  ms := TStringlist.Create;
end;

...

procedure TForm1.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
  sc.free;
  tx.Free;
  ms.Free;
end;

Dabei ist jedoch beim schließen ein Fehler aufgetaucht:

[Klaus01]

Deine Aufrufe von *.free sollte nicht in die FormCloseQuery
sondern nach onClose.

In FormClosQuery sollte nur die CanClose Variable entsprechend gesetzt werden.

Grüße
Klaus

[florpp]

:gruebel: In OnClose passiert genau das selbe...

[Kroko1999]

Erstellen im FormCreate-Ereignis und zerstören im FormDestroy-Ereignis ist imho die beste Lösung!

[DeddyH]

Bei mir tritt der Fehler nicht auf. Gibst Du die Stringlisten noch an anderer Stelle frei? Falls ja, dann ersetz mal ggf. StringList.Free durch FreeAndNil(StringList)

[edit]

Zitat:

Zitat von Kroko1999

Erstellen im FormCreate-Ereignis und zerstören im FormDestroy-Ereignis ist imho die beste Lösung!

Wenn er schon globale Variablen benutzt, könnte er auch initialization und finalization verwenden, das wäre IMO noch besser. [/edit]

[Kroko1999]

dann sollte er die globalen in lokale Klassen-Variablen umwandeln!

[DeddyH]

Sehe ich genauso.

[taaktaak]

Moin, Moin.

Ich gebe die Instanzen zwar auch immer am Programmende frei; trotzdem die folgende (vielleicht naive) Frage: Welche Auswirkungen hat es denn, wenn man das nicht tut? Bleibt der Speicher dann für Windows reserviert und ist bis zum nächsten Systemstart nicht mehr nutzbar?

Gruß Ralph

[Die Muhkuh]

Nein, Windows räumt da schon selbst auf.

[sirius]

Und vor allem räumt zuerst Delphi bzw. der Speichermanager auf.

[DeddyH]

Ich will meine Hand nicht dafür ins Feuer legen, aber AFAIK tritt dann der Garbage Collector in Aktion (verlassen würde ich mich aber nicht darauf).

[taaktaak]

Hmmm, und warum gibt man dann diese Instanzen zum Programmende frei? Das ist doch dann überflüssig!?

[florpp]

... das heißt ich kann es theoretisch einfach weglassen?

[mkinzler]

GC unter Win32?

[taaktaak]

GC ??

// Garbage Collector - oder?

[DeddyH]

Heißt der unter Win32 anders? Ich meine jetzt nicht den von Java :mrgreen:

[Die Muhkuh]

Ja.

GC gibts imho nur unter .NET.

Aber da Windows ja auch aufräumt, hat es ja auch eine Art GC :stupid:

[taaktaak]

Gibt es eine abschließende Antwort der Experten auf die offene Frage:

Sollte man in Anbetracht dieser Tatsache dann nicht auf das Freigeben der Instanzen unmittelbar vor Beendigung des Programmes verzichten?

Ralph

[DeddyH]

Sollte? Ein klares Nein.

[taaktaak]

Hmmm, man sollte also nicht darauf verzichten.

Warum nicht, wenn es doch offenbar überflüssig ist?
Ist das nicht etwas verwirrend?

Gruß Ralph

[Apollonius]

In Destruktoren werden ja auch andere Dinge gemacht als die eigentliche Zerstörung (die erfolgt in FreeInstance).

[omata]

Deine Fragen wurden schon beantwortet...

Zitat:

Zitat von Kroko1999

Erstellen im FormCreate-Ereignis und zerstören im FormDestroy-Ereignis ist imho die beste Lösung!

Zitat:

Zitat von Kroko1999

dann sollte er die globalen in lokale Klassen-Variablen umwandeln!

Also so...

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs;

type
  TForm1 = class(TForm)
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
  private
    { Private-Deklarationen }
    Fsc   : TStringlist;
    Ftx   : TStringlist;
    Fms   : TStringlist;
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;
  // hier werden niemals eigene Variablen deklariert.

implementation

{$R *.dfm}

procedure TForm1.FormCreate(Sender: TObject);
begin
  Fsc := TStringlist.Create;
  Ftx := TStringlist.Create;
  Fms := TStringlist.Create;
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  Fsc.free;
  Ftx.Free;
  Fms.Free;
end;

end.

Gruss
Thorsten

[Kroko1999]

@omata: ja, aber dann bitte mit einem F vor privaten Variablen!

[omata]

Ups, du hast natürlich recht. Habs nur kopiert, sorry :oops:

[Helmi]

Zitat:

Zitat von Kroko1999

@omata: ja, aber dann bitte mit einem F vor privaten Variablen!

auch wenns offtopic ist, aber warum?

[DeddyH]

Damit Du gleich erkennen kannst, dass Du auf ein privates Feld zugreifst.

[Apollonius]

Das ist keine Pflicht, aber praktisch alle Styleguides empfehlen, die Namen von Feldern mit f beginnen zu lassen.

[Kroko1999]

Zitat:

Zitat von DeddyH

Damit Du gleich erkennen kannst, dass Du auf ein privates Feld zugreifst.

ja und es nennt sich Style-Guide(o.s.ä.)

[Helmi]

Danke für die Erklärung!

aber mein Styleguides sagt das nicht - ist nämlich von mir :-)
Ich komm so, wie ich es bisher mach ganz zurecht

[DeddyH]

Ich hole mal ein bisschen aus: wenn Du Felder einer Klasse nach außen hin bekannt machen willst, gewährst Du keinen direkten Zugriff auf sie, sondern definierst Schnittstellen (Getter- und Settermethoden). Die Variable wird dann auch nicht als Variable angesprochen, sondern als Eigenschaft (property). Mal ein Beispiel (Feld soll nur einen Wert zwischen 1 und 1000 annehmen können):

Delphi-Quellcode:

type
  TMyClass = class
  ...
  private
    FFeld: integer;
    procedure SetFeld(value: integer); //Setter
    function GetFeld: integer;         //Getter
    ...
  public
    property Feld: integer read GetFeld write SetFeld;
    ...
end;

procedure TMyClass.SetFeld(value: integer);
begin
  if (value in [1..1000]) then
    FFeld := value;
end;

function TMyClass.GetFeld: integer;
begin
  Result := FFeld;
end;

So funktioniert OOP ;)

[Helmi]

na so bau ich ja auch meine Sachen auf
aber eben nur ohne F

[DeddyH]

Dann ersetz in meiner Setter-Methode mal FFeld durch Feld... *bumm*. Genau das ist der Grund, warum es StyleGuides gibt.

[Helmi]

Wenn man konsequent einen Style durchzieht, egal ob dieser
jetzt empfohlen wird oder einfach selbst entwickelt wurde,
dann passiert so was nicht

aber egal - wir sind offtopic!

[Muetze1]

Da es zur Originalfrage noch nicht so ganz heraus kam, noch folgende Ergänzung:

OnCloseQuery dient der Nachfrage, ob das Fenster geschlossen werden kann. Dort programmiert man den altbekannten Dialog rein: "Daten vorm beenden speichern" bzw. "Programm wirklich beenden" um bei einer negativen Antwort des Nutzers das Schliessen abzuwenden (CanClose := false). Somit kann diese Routine mehrfach aufgerufen werden und da in dem aufgezeigten Beispiel nur .Free verwendet wurde ohne die Instanzenvariable auf nil zu setzen, knallt es nach einmaligen durchlaufen des Ereignisses.