AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign Delphi Unterschied zwischen nil, FreeAndNil und Free in TForm

Unterschied zwischen nil, FreeAndNil und Free in TForm

Ein Thema von michele_tedesco · begonnen am 7. Apr 2014 · letzter Beitrag vom 14. Apr 2021
Antwort Antwort
Seite 3 von 3     123
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.007 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#21

AW: Unterschied zwischen nil, FreeAndNil und Free in TForm

  Alt 10. Apr 2014, 22:09
Ich würde, nur weil ich meine Forms nicht über 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.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie (10. Apr 2014 um 22:13 Uhr)
  Mit Zitat antworten Zitat
Jumpy

Registriert seit: 9. Dez 2010
Ort: Mönchengladbach
1.733 Beiträge
 
Delphi 6 Enterprise
 
#22

AW: Unterschied zwischen nil, FreeAndNil und Free in TForm

  Alt 11. Apr 2014, 09:06
"ich klick irgendwo drauf anstatt eine Zeile Source zu schreiben"
Ich dachte das wär Datasnap
Ralph
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#23

AW: Unterschied zwischen nil, FreeAndNil und Free in TForm

  Alt 11. Apr 2014, 09:14
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.
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.336 Beiträge
 
Delphi 11 Alexandria
 
#24

AW: Unterschied zwischen nil, FreeAndNil und Free in TForm

  Alt 11. Apr 2014, 09:56
[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]
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)

Geändert von stahli (11. Apr 2014 um 11:06 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.016 Beiträge
 
Delphi 12 Athens
 
#25

AW: Unterschied zwischen nil, FreeAndNil und Free in TForm

  Alt 13. Apr 2021, 14:18
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat
TurboMagic

Registriert seit: 28. Feb 2016
Ort: Nordost Baden-Württemberg
2.772 Beiträge
 
Delphi 12 Athens
 
#26

AW: Unterschied zwischen nil, FreeAndNil und Free in TForm

  Alt 13. Apr 2021, 21:47
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...
  Mit Zitat antworten Zitat
Redeemer

Registriert seit: 19. Jan 2009
Ort: Kirchlinteln (LK Verden)
1.010 Beiträge
 
Delphi 2009 Professional
 
#27

AW: Unterschied zwischen nil, FreeAndNil und Free in TForm

  Alt 13. Apr 2021, 23:51
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.
Janni
2005 PE, 2009 PA, XE2 PA
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.016 Beiträge
 
Delphi 12 Athens
 
#28

AW: Unterschied zwischen nil, FreeAndNil und Free in TForm

  Alt 14. Apr 2021, 11:36
Sorry, stimmt ... das böse MainForm.
Hatte "Form1" nur genommen, weil es hier überall stand.


Ein neues Projekt ist eine Codevorlage.
Da würde diese Aktion eh nicht greifen, da nicht wirklich eine FormUnit hinugefügt wird.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests

Geändert von himitsu (14. Apr 2021 um 12:52 Uhr)
  Mit Zitat antworten Zitat
TurboMagic

Registriert seit: 28. Feb 2016
Ort: Nordost Baden-Württemberg
2.772 Beiträge
 
Delphi 12 Athens
 
#29

AW: Unterschied zwischen nil, FreeAndNil und Free in TForm

  Alt 14. Apr 2021, 15:15
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
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:09 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz