Unterschied zwischen nil, FreeAndNil und Free in TForm

[Stevie]

Ich würde, nur weil ich meine Forms nicht über

Delphi-Quellcode:

Application.CreateForm

erstellen lasse (denn das ist es im Kern, worin sich das von Sir Rufo beschriebe unterscheidet), keineswegs von nicht RAD sprechen. RAD ist sehr viel mehr und keineswegs "ich klick irgendwo drauf anstatt eine Zeile Source zu schreiben" - womit es aber viele gleichsetzen.

[Jumpy]

Zitat:

Zitat von Stevie (Beitrag 1255251)

"ich klick irgendwo drauf anstatt eine Zeile Source zu schreiben"

Ich dachte das wär Datasnap :-D

[Dejan Vu]

Ich entwickle seit Delphi 2 sehr schnell funktionierende Anwendungen. Ich nenne das 'Rapid Application Development'. Mehr ist das doch nicht. Aber auch nicht weniger, denn das ist das Gute an Delphi, aber auch an -z.B. Visual FoxPro.

RAD ist imho kein Paradigma, sondern ein Resultat eines so konzipierten Frameworks und der IDE. Der Ansatz von Visual FoxPro ist z.B. ein komplett anderer, trotzdem entwickelt man Programme in kürzester Zeit.

Das mal zum Thema RAD oder nicht RAD (APP).

Nähkästchen: Wenn ich das 30.ste Formular erstelle und beim starten merke, das dieser nun 10 Sekunden dauert, dann denke ich darüber nach, was ich hier so treibe und räume auf. Nun ja. Eigentlich fang ich erst gar nicht an, diesen Mist zu machen, denn jede Form bekommt eine Klassenmethode zum erzeugen und anzeigen.

Delphi-Quellcode:

Type
  TForm1 = Class (TForm)
  ...
  class function Show (data :TSomeData) : Boolean;
  end;

implementation

class function TForm1.Show (data : TSomeData) : Boolean;
Begin
  With TForm1.Create(nil) do begin
     InitData(data); 
     Result := ShowModal = mrOK;
     if Result then WriteBackData(data);
     Release;
  end
end;

Ach bitte: Keine Kommentare wegen dem bösen 'With'. Take it or leave it. I take it because I know what I'm doing.

Die Routinen sehen natürlich nicht alle 100% identisch aus, aber im Prinzip sorge ich dafür, das ich mit einem Aufruf das Formular anzeige und das bisserl Logik dort verankere. Ich komme dabei zu 99% komplett ohne irgendwelche Bindings aus. Und, und darauf wollte ich hinaus: Ich komme komplett ohne Formularvariablen aus.

Damit kann ich dann sehr einfach in einem Buttonclick ein Kindformular öffnen, womit wieder 99% der Anwendungsfälle abgedeckt sind.

Die restlichen 1% (nicht modale Fenster, Threads und Statusaktualisierungen) erschlage ich mit Messages oder was mir sonst noch so einfällt. Und hier kommen dann globale Variablen ins Spiel. Ob ich diese globalen Variablen hinter einem Controller oder Container verberge, ist ja wurscht. 'Form1' ist für alle sichtbar, aber eben nur lesend. Da handle ich nach der Maxime: Wer Dreck macht, muss aufräumen, bzw. wer Form1 instantiiert, ist dafür verantwortlich, es auf den Müll zu schmeißen. So ein Container ist hier eine gute Sache, denn über den kann jeder Thread eine bitte zur Aktualisierung seines Status an das Formular schicken. Der Container entscheidet bzw. implementiert die Technik, wie die Form das mitbekommt, so bin ich von Synchronize und Queue unabhängig.

Die Produktivität ist enorm, RAD at its best. Nicht weil ich so toll bin, sondern weil dieses Schrottdelphi (D7, XE) es mir wirklich leicht macht.

Der Preis? Bei wachsender Komplexität wird die Anwendung sehr schnell nicht mehr leicht wartbar. Mit wachsender Komplexität ist aber nicht die Anzahl der Formulare gemeint, sondern die Businesslogik. Insofern würde ich bei großen Projekten auf RAD pfeifen, denn unterm Strich bin ich damit nicht schneller, eher im Gegenteil.

Wenn ich aber auf irgend ein Riesenformular den 1000 Menüpunkt unterbringen soll, der noch ein Fenster aufmacht (Herr, schmeiss Hirn vom Himmel), dann mache ich genauso weiter (RAD, klick, bunt) , denn komplexer wird die Applikation dadurch ja nicht. Nur noch schlechter bedienbar.

Abschließend will ich noch etwas loswerden: Ich bin froh, das man hier doch sehr hochwertige Beiträge findet. Die Aktivität der letzten Tage deuteten eher auf ein ziemlich eingeschlafenes Forum hin. :thumb:

[stahli]

[OT]
Wir kommen etwas vom Thema ab, aber ich würde an der Stelle gern mal auf diesen Thread verweisen: http://www.delphipraxis.net/176478-m...realitaet.html

Vielleicht kannst Du ja mal ein kleines Demoprojekt bauen und/oder ein kleines Video aufnehmen, mit dem man Deine Arbeitsweise live nachvollziehen kann. Mich würde das interessieren, da ich eigentlich eher den gegenteiligen Ansatz anstrebe - wenn ich Deinen Beitrag richtig interpretiere.
Ich finde Bindings gerade sehr erstrebenswert, wenn sie gut umgesetzt sind (also nicht die von Emba).
[/OT]

[himitsu]

Delphi-Quellcode:

Form1.Free;
Form1 := nil;
// oder 
FreeAndNil(Form1);

von außerhalb. (niemals im eigenen OnClose oder Dergleichen)

Wobei FreeAndNil ein "Schutz" ist, denn eigentlich macht es "NilAndFree", damit selbst bei einer Exception im Destructor die Variable definitiv immer auf NIL steht.

Delphi-Quellcode:

// im OnClose
Action := caFree;
if Form1 = Self then Form1 := nil;  // das vielleicht ach erst im OnDestroy

"irgendwas" auf NIL zu setzen ist jedenfalls nicht die gute Art,
denn ist die z.B. Form mehrfach geladen, wenn würde man vielleicht den "falschen" Instanz-Zeiger aus der Variable löschen.

Beispiel: Die Form wird via Form1.Release; freigegeben, also nicht jetzt, sondern später.
in der Zwischenzeit wird die Form erneut angezeigt (neue Instanz), bevor die VCL zum verarbeiten der Message kam,
also die alte Instanz wird erst freigegeben, wenn die Neue schon da ist und in der Variable steht womöglich schon der neue Instanz-Zeiger.

[EDIT]
Nicht "vielleicht", sondern "definitiv",
denn bei einem direkten .Free wird OnClose garnicht aufgerufen.


[INFO] Ich weiß, is bissl spät, aber wenn Andere das grade lesen, dann vielleicht doch nochmal bissl was genauer beschrieben.

[TurboMagic]

Zitat:

Zitat von Stevie (Beitrag 1254974)

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).

Dem stimme ich zu.
Ich glaube auch, dass es bisher keine IDE Einstellung "Forms nie automatisch erzeugen" gibt.
Das fände ich praktisch, sollte aber natürlich nicht beim Anlegen des Hauptformulars eines neuen
Projektes greifen...

[Redeemer]

Zitat:

Zitat von himitsu (Beitrag 1487045)

Beispiel: Die Form wird via Form1.Release; freigegeben, also nicht jetzt, sondern später.

Schlechtes Beispiel, denn wenn Form1 das Standardformular ist, funktioniert Release AFAIR nicht. Bzw. nicht wie man erwarten würde.

[himitsu]

Sorry, stimmt ... das böse MainForm.
Hatte "Form1" nur genommen, weil es hier überall stand. :angle2:


Ein neues Projekt ist eine Codevorlage.
Da würde diese Aktion eh nicht greifen, da nicht wirklich eine FormUnit hinugefügt wird.

[TurboMagic]

Zitat:

Zitat von TurboMagic (Beitrag 1487087)

Zitat:

Zitat von Stevie (Beitrag 1254974)

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).

Dem stimme ich zu.
Ich glaube auch, dass es bisher keine IDE Einstellung "Forms nie automatisch erzeugen" gibt.
Das fände ich praktisch, sollte aber natürlich nicht beim Anlegen des Hauptformulars eines neuen
Projektes greifen...

Sehe gerade: diese Einstellung gibt's wirklich!
Unter Tools/Optionen/Benutzeroberfläche/Formular-Designer/Autom. Formulare & Datenmodule