Unterschied zwischen nil, FreeAndNil und Free in TForm

[himitsu]

Im Prinzip wurden diese Variablen wohl nur angelegt, damit man die anderen Forms erreichen konnte, wenn man alle Forms automatisch erstellen lässt.

Aber am Liebsten würde ich die auch abschaffen oder zumindestens anders implementieren wollen.

[Stevie]

Zitat:

Zitat von Dejan Vu (Beitrag 1254970)

Zitat:

Zitat von Sir Rufo (Beitrag 1254959)

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.

Wenn es wirklich 90% der Delphi Programmierer so machen (wovon ich nicht ausgehe), dann machen es 90% der Delphi Programmierer falsch. Da gibt es, so hart es klingt, nix dran zu rütteln. Die globale Form Variable, die bei jedem Erstellen einer neuen Formklasse standardmäßig in der Unit angelegt wird, kann man getrost löschen, wenn man diese Form nicht in den Projekteinstellungen in die "Wird beim Starten automatisch erzeugt" Liste aufnimmt, denn für nix anderes ist sie da (und selbst das hätte man vor über 15 Jahren anders designen können, aber nun haben wir halt den Salat).

Mit dieser Variablen zu arbeiten ist deshalb unüberlegt, weil man sich damit verwehrt, mal mehr als eine Instanz eines solchen Forms zu haben (das soll in der Tat vorkommen).

[Daniel]

Moment. Bevor Ihr Euch weiter über die Vewendung globaler Variablen auslasst, lest zuvor bitte alle (!) existierenden Threads zu diesem Thema. Wenn Ihr danach dann noch etwas substantiell Neues beizutragen habt, dann gern her damit.

[Dejan Vu]

Ich wollte keine Diskussion über Sinn und Unsinn globaler Variablen anzetteln, sondern die korrekte Beantwortung einer Frage in den Mittelpunkt stellen: Eine Frage nach dem Unterschied zwischen drei Codezeilen sollte man mit der Erklärung des Unterschiedes der drei Codezeilen beantworten und nicht mit einem "Alles Käse". Zumindest war das mein Eindruck der Antworten.

Zitat:

Zitat von Stevie (Beitrag 1254974)

Wenn es wirklich 90% der Delphi Programmierer so machen (wovon ich nicht ausgehe)

Wieso nicht? Der weitaus größte Teil der Programmierer in der freien Wildbahn sind nach meinen Erfahrungen (und davon hab ich leider Einiges) keine gelernten IT-ler. Sie sind froh, das es läuft. Der Code, der sich in diesem Bereich tummelt, ist schmerzgrenzenausleuchtend. Aber es ist so, man kann nicht alles um- und neuschreiben und deshalb sollte man damit leben. Und Fragen aus diesem Bereich (von den armen Programmierern, die das ausbaden müssen) entsprechend beantworten.

Ach, und das es 'falsch' ist, kann auch nicht stimmen: Etwas 'falsches' funktioniert i.A. nicht (Das ist mein Verständnis von 'falsch'). Es ist einfach nicht state-of-the-art, ebenso wie ein Verbrennungsmotor, Plastiktüten oder Schnurrbärte (oder sind die wieder In?); Trotzdem lebt man damit. Man fährt auf lange Sicht nicht gut mit diesen Dingen, denn sie sind nicht nachhaltig, beinhalten Stolperfallen, machen einem das Leben schwer usw. Wobei Schnurrbärte auch bald wieder in Mode sein werden.

[michele_tedesco]

Zitat:

Zitat von Sir Rufo (Beitrag 1254959)

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.

@Sir
Kannst du ein konkretes Beispiel mit dem Unterschied zwischen "globalen Variablen für die Forms" und "globalen Variablen für diese Formklasse".
Und natürlich noch ein drittes Beispiel, wo aufzeigt wie du ein Form/eine Formklasse behandelst :)

Danke :thumb:

[Sir Rufo]

Delphi-Quellcode:

type
  TForm1 = class( TForm )
    Edit1 : TEdit;
    procedure Foo;
  end;

var
  Form1 : TForm1;

implementation

uses
  Form2Unit;

procedure TForm1.Foo;
begin
  // globale Variable für die Forms

  Form2.Show;  

  // globale Variable für diese Formklasse

  Form1.Edit1.Text := 'Foo'; // Bezug auf die Instanz, die in der Variablen Form1 hinterlegt ist

  // wenn schon, dann

  Self.Edit1.Text := 'Foo'; // Bezug auf die eigene Instanz

  // oder einfach

  Edit1.Text := 'Foo'; // Bezug auf die eigene Instanz
end;

Wenn man basierend auf dem RAD Ansatz programmiert ist daran erst einmal nichts auszusetzen, leider verstehen die wenigsten diesen Ansatz, brechen die Vereinbarungen (auf die man sich mit RAD einlässt) und wundern sich warum das nicht funktioniert.

RAD-Vereinbarungen:

• Die Form-Instanzen werden beim Start der Anwendung initialisiert und die Referenzen dazu werden in globalen Variablen gespeichert
• Die globalen Variablen dürfen nur lesend benutzt werden
• Diese Instanzen dürfen niemals freigegeben werden (darum kümmert sich die Anwendung selber beim Beenden)
• Von jeder Form-Klasse darf es nur eine Instanz (die beim Start erzeugte) geben

Folgende Codeteile brechen diesen Ansatz (kein Anspruch auf Vollständigkeit):

• Delphi-Quellcode:

  Form1 := nil;

• Delphi-Quellcode:

  FreeAndNil( Form1 );

• Delphi-Quellcode:

  Form1.Free;

• Delphi-Quellcode:

  procedure TForm1.Form1Close( Sender:TObject; var Action : TCloseAction );
  begin
    Action := caFree;
  end;

• Delphi-Quellcode:

  procedure Foo;
  var
    LForm : TForm1;
  begin
    LForm := TForm1.Create( nil );
    try
      LForm.ShowModal;
    finally
      LForm.Free;
    end;
  end;

Wenn die Anwendung diese Vereinbarungen einhalten kann, dann spricht nichts gegen diesen Ansatz (ausser die Anforderung von morgen ...)

[himitsu]

Zitat:

Bezug auf die Instanz, die in der Variablen Form1 hinterlegt ist

Besonders gut zu beobachten war es da, wo ausversehn irgendwie das FormCreate für Form1 doppelt in die DPR reingekommen ist.
Sichtbar war dabei die erste Instanz, aber in der Variable stand die zweite Instanz, weil die ja zuletzt die Variable überschrieb.

Der Benutzer schrieb also was in Instanz 1, aber via Form1-Variable war das Geschriebene ntürlich nicht vorhanden.


Oder man erstellt die Form mal dynamisch, weist aber nix der globalen Variable zu, sondern nutzt z.B. nur eine lokale Variable, oder gar blos ein WITH, weil die Form nur innerhalb einer Ereignismethode "kurz" verwendet und dann die Form sofort wieder freigegeben wird.

[Popov]

Um ehrlich zu sein bin ich seit Tagen etwas verwirrt, weil ich nicht wirklich weiß ob ich das Problem verstehe. Geht es bei den globalen Form-Variablen um Grundlagen-Fragen, so dass ich die Frage nur an der falschen Stelle, also zu hoch ansetzte? Oder geht es hier um höhere Programmierung, ich also das Spezielle nicht erkenne?

[Sir Rufo]

Wenn es sich um eine RAD-Anwendung handelt, dann ist die Verwendung der globalen Form-Variablen erlaubt (gehören ja zum Konzept), aber nur lesend und die Instanzen müssen tabu sein (gehört ebenfalls zum Konzept).

Die Ausgangsfrage:

Zitat:

Zitat von datasportdev (Beitrag 1254922)

In einer legacy Applikation habe ich an ganz vielen Orte

Delphi-Quellcode:

Form1 := nil

gesehen im

Delphi-Quellcode:

OnClose

(

Delphi-Quellcode:

Form1.FormClose

), anstellen von

Delphi-Quellcode:

Action := ca.Free

.

Was ist der Unterschied wenn ich in

Delphi-Quellcode:

FormClose

• Delphi-Quellcode:

  Action := ca.Free

• Delphi-Quellcode:

  Form1 := nil

• Delphi-Quellcode:

  FreeAndNil(Form1)

aufrufe?

In einer RAD-Anwendung sind alle drei Punkte falsch, denn alle verletzen die Vereinbarung, die ich mit RAD eingehe.

In einer nicht RAD-Anwendung ist der erste Punkt erlaubt aber die anderen beiden Punkte sind falsch, denn dort sind die globalen Form-Variablen absolut tabu (am besten werden die sofort gelöscht).

Es gibt auch noch so einen Mischmasch aus RAD und nicht RAD, den würde ich aber dringend empfehlen zu eliminieren. Also nur das Haupt-Formular (auch zu finden auch unter

Delphi-Quellcode:

Application.MainForm

) wird zum Anwendungsstart erzeugt, alle anderen dynamisch.

[michele_tedesco]

Danke für die super und sehr ausführliche Erklärung Sir Rufo :thumb: :-D