Unterschied zwischen nil, FreeAndNil und Free in TForm

[michele_tedesco]

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?

[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:

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?

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
  Delphi-Quellcode:

  FreeAndNil( Form1 );

• meistens falsch
  Delphi-Quellcode:

  Form1 := nil;

  , auf jeden Fall ungeschickt und die Instanz wird nicht freigegeben
• richtig
  Delphi-Quellcode:

  Action := caFree;

ist.

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

Und in der Variablen

Delphi-Quellcode:

Form1

ist ja auch nicht gesichert die Instanz-Referenz zur aktuellen Instanz drin ;)

[michele_tedesco]

SUPER! Vielen Dank :-) :thumb:

[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]

Delphi-Quellcode:

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:

Zitat von Sir Rufo (Beitrag 1254926)

[*]meistens falsch

Delphi-Quellcode:

Form1 := nil;

, auf jeden Fall ungeschickt und die Instanz wird nicht freigegeben

Zitat:

Zitat von himitsu (Beitrag 1254951)

Delphi-Quellcode:

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:

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.

[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

[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