Unterschied zwischen nil, FreeAndNil und Free in TForm

[michele_tedesco]

In einer legacy Applikation habe ich an ganz vielen Orte Form1 := nil gesehen im OnClose ( Form1.FormClose ), anstellen von Action := ca.Free .

Was ist der Unterschied wenn ich in FormClose

• Action := ca.Free
• Form1 := nil
• FreeAndNil(Form1)

aufrufe?

[Sherlock]

In der alten Application (alte Delphiversion) gabs eventuell die Action noch nicht.
Grundsätzlich sollte ein .Free ja reichen. nil setzen manche, weil sie zur Laufzeit auf nil abfragen wollen...um zu vermeiden, ein fregegebenes oder noch nciht erzeugtes Objekt zu benutzen. Aber vom Prinzip her reicht Free vollkommen aus.

Sherlock

[mkinzler]

Zitat von datasportdev:

In einer legacy Applikation habe ich an ganz vielen Orte Form1 := nil gesehen im OnClose ( Form1.FormClose ), anstellen von Action := ca.Free .

Was ist der Unterschied wenn ich in FormClose

• Action := ca.Free
• Form1 := nil
• FreeAndNil(Form1)

aufrufe?

Das erste gibt beim Schließen die Formularklasse frei (.Free wird aufgerufen)
Das 2. setzt nur die Vraible auf Nil, ohne die Instant freizugeben, diese existiert weiterhin.
Das 3. gibt die Instanz freu und setzt die Referenzvariable zurück.

[Sir Rufo]

Der Unterschied ist, dass in TForm.OnClose

• immer falsch FreeAndNil( Form1 );
• meistens falsch Form1 := nil; , auf jeden Fall ungeschickt und die Instanz wird nicht freigegeben
• richtig Action := caFree;

ist.

Immer unter dem Gesichtspunkt, dass die Form-Instanz auch wirklich freigegeben werden soll.

Und in der Variablen Form1 ist ja auch nicht gesichert die Instanz-Referenz zur aktuellen Instanz drin

[michele_tedesco]

SUPER! Vielen Dank

[Popov]

Vielleicht noch ein Beispiel:

Delphi-Quellcode:

var
  sl: TStringList;
begin
  sl := TStringList.Create;
  sl.Add('Hallo');
  ShowMessage(IntToStr(sl.Count));

  sl.Free;

  ShowMessage(IntToStr(sl.Count));
end;

Hier gibt es u. U. keine Fehlermeldung, obwohl das Objekt freigegeben wurde, bzw. es wurde nur das Objekt freigegeben, ohne jedoch die Adresse zu löschen. U.U. hat sl also noch die alte Adresse und die zeigt ins Nichts und das Programm funktioniert mit Fehler, liefert also falsche Daten.

Delphi-Quellcode:

var
  sl: TStringList;
begin
  sl := TStringList.Create;
  sl.Add('Hallo');
  ShowMessage(IntToStr(sl.Count));

  FreeAndNil(sl);

  ShowMessage(IntToStr(sl.Count));
end;

Hier wird auch die Adresse von sl gelöscht, genilt, bzw. auf 0 gesetzt. Hier gibt es eine Fehlermeldung.

[himitsu]

Form1 := nil macht garnichts, außer die Variable auf nil zu setzen ... die Form interessiert das aber sowas von garnicht.

Wofür es aber hilft, wenn man irgendwo noch auf Form1 zugreift, nachdem die Form schon freigegeben wurde ... dann bekommt man verständlichere Exceptions mit "Zugriffsverletzung bei Adresse 0".

[Dejan Vu]

Zitat von Sir Rufo:

[*]meistens falsch Form1 := nil; , auf jeden Fall ungeschickt und die Instanz wird nicht freigegeben

Zitat von himitsu:

Form1 := nil macht garnichts, außer die Variable auf nil zu setzen ...

Die Intention der Anweisung scheint nicht ganz klar zu sein: "Die Form1 ist ab jetzt ungültig und soll nicht mehr verwendet werden." Wenn ich die Instanz auf nil setze und an anderer Stelle prüfe, ob diese Instanz != nil ist (und nur dann eine bestimmte Aktion ausführe), scheint das eine durchaus einfache Möglichkeit zu sein, sicherzustellen, das nur bei einer sichtbaren/gültigen/aktiven Form bestimmte Aktionen ausgeführt werden.

Also "ungeschickt", "meistens falsch" oder "macht gar nichts" ist vielleicht ein wenig unüberlegt.

Wäre natürlich auch denkbar, das der ursprüngliche Programmierer wirklich keinen blassen Schimmer hatte.

[Sir Rufo]

Das Benutzen der globalen Variablen für die Forms ist unüberlegt.
Das Benutzen der globalen Variablen für diese Formklasse gleicht einem Schuss ins eigene Knie.

[Dejan Vu]

Zitat von Sir Rufo:

Das Benutzen der globalen Variablen für die Forms ist unüberlegt.
Das Benutzen der globalen Variablen für diese Formklasse gleicht einem Schuss ins eigene Knie.

Das ist RAD à la Delphi, mit dem so 90% der Programmierer arbeiten. Die nun alle als 'unüberlegt' und Schützen'ins eigene Knie' zu bezeichnen ist auch eine Form der Respektbekundung.

Interessant, was sich hier so tummelt.