Form zur Laufzeit erzeugen

[hanspeter]

Hallo,

ich habe meine Programme bisher immer so angelegt, das eine Mainform beim Programmstart erzeugt wird.
Alle anderen Formen werden erst dann, wenn sie benötigt werden erzeugt und am Ende wieder freigegeben.
(Action := cafree; )

Ich habe jetzt mit einem Freiberufler zu tun, der sich für einen Delphi Superguru hält und meint das alle Fenster
undbedingt beim Programmstart erzeugt werden müssen und baut mir Projekte zwischenzeitlich so um.
Inzwischen werden 40 bis 50 Forms sofort bei Programmstart erzeugt und nur verborgen und bei Bedarf angezeigt und dann wieder verborgen.
Mir streuben sich bei dieser Methotik ein bischen die Haare, vielleicht verstehe ich aber auch den tieferen Sinn nicht.
Was ist Eure Meinung dazu?

Gruß Peter

[mkinzler]

Also eine solche Ansicht, zeugt eher von weniger "Guru"

[DeddyH]

Vielleicht sollte er mal 2 Tage über seinem Konzept meditativ verharren. Möglicherweise kommt ihm dann die Erleuchtung :mrgreen:

[himitsu]

Wenn eine Form häufig und oder sehr schnell angezeigt werden muß, dann kann ein "Vorladen" dieser Form schon angebracht sein, anstatt sie ständig (aufwändig) neu erzeugen zu müssen.

Ansonsten verlängert es nur sinnlos den Programmstart und es verschwendet mehr wertvolle Resourcen.

So wird in Delphi z.B. die OutOfMemory-Exception schon bei Programmstart erzeugt, weil es sonst ja passieren kann, daß im richtigen Moment dieses nicht mehr möglich ist.

[DeddyH]

Wer öffnet und schließt schon ständig 50-60 Formulare? Es macht ja Sinn, Formulare, die im normalen Programmablauf häufig benötigt werden, in der automatischen Formularerstellung zu belassen. Aber das trifft sicherlich nicht auf jedes noch so kleine Spezialfensterchen zu.

[blackfin]

Ich hab schonmal so einen "Guru" sagen hören, dass man sich bei Delphi um die Objekt-Freigabe nicht kümmern muss, da es Delphi ja alles selbst macht!
Als ich ihm gesagt habe, dass das für selbst erzeugte Objekte nicht zutrifft, hat er mir das erstmal gar nicht geglaubt...
Soviel zum Thema Guru :lol:

Ansonsten halte ich die sture Ansicht, alles müsste beim Programmstart erzeugt werden, für puren Blödsinn.
Das kommt immer auf den Anwendungsfall an und muss für jede Applikation neu entschieden werden, was das sinnvollste ist.
Was bringt es mir, wenn ich 200 Formulare beim Programmstart erzeuge und deswegen der User erstmal 1 Minute nichts sieht? Nichts..

[mkinzler]

Zitat:

Als ich ihm gesagt habe, dass das für selbst erzeugte Objekte nicht zutrifft

Kommt darauf an, wenn es sich um Komponenten handelt und diese einen Owner haben, geht das schon oder wenn diese in Listen abgelegt werden.

[blackfin]

Schon klar, ich glaube aber, jeder weiss, was damit gemeint ist :)
Dann korrigiere ich: "Als ich ihm gesagt habe, dass das für selbst erzeugte Objekte nicht immer zutrifft, hat er mir das erstmal gar nicht geglaubt..."

besser? :D

[hanspeter]

Ein Großteil der Fenster sind modale Dialoge die mit showmodal sichtbar und mit visible = false verborgen werden. Viele werden nur sporadisch oder innerhalb einer Session garnicht gebraucht.
Zumindest bis W2000 gab es bei einer Unmenge an Fenstern ein Window - Resourcenproblem.

Gruß

[DeddyH]

Wie bereits gesagt: Formulare, die bei der "normalen" Programmnutzung häufig gebraucht werden, kann man IMO ruhig automatisch erzeugen lassen. Stellt man die anderen auf "dynamisch" um, hat man meist eine gute Balance zwischen Laufzeitverhalten und Speichernutzung. Da ist ein wenig Fingerspitzengefühl angebracht. Jedenfalls ist weder die komplette automatische noch die dynamische Erzeugung immer der Königsweg.

[Bernhard Geyer]

Zitat:

Zitat von hanspeter (Beitrag 1043128)

Zumindest bis W2000 gab es bei einer Unmenge an Fenstern ein Window - Resourcenproblem.

Gibts es auch unter XP/Vista/Win7. Die Grenzen sind nur "etwas" weiter nach hinten verschoben.

Also das vorgehen alles beim Programmstart zu erzeugen halte ich für blödsinn. Wir gehen eigentlich auch immer her alle von Delphi erzeugten globalen Formularvariablen gleich aus dem Quellcode wieder zu löschen um hier keine Probleme damit zu haben versehentlich ab und zu dieses Variable zu verwenden auch wenn man in einer ganz anderen Instanz ist.

[Hansa]

Ich sehe das ähnlich : Vorgehensweise ist nicht gerade hilfreich. Auch die "Gurus" kochen nur mit Wasser. Werden 50 Forms oder mehr permanent im Speicher gehalten, Variablen verändert etc., dann ist das Programm in einem gewissen Zustand, der ohne allergrösste Vorsicht nicht als sicher bezeichnet werden kann.

Es wäre also eine gewisse Vorsichtsmassnahme, die Forms immer wegzumachen und bei Bedarf neu zu createn. Inkl. Initialisierungen usw. Der Speicherplatzbedarf spielt da nicht mal die grosse Rolle, die Logik aber schon.

[xZise]

Moin,
ich sehe den Vorteil bei der dynamischen Erstellung daran, dass es automatisch vergisst nach dem Freigeben.

MfG
Fabian

[Hansa]

Was soll was vergessen ? :shock:

[wicht]

Zitat:

Zitat von Hansa (Beitrag 1043165)

Variablen verändert etc., dann ist das Programm in einem gewissen Zustand, der ohne allergrösste Vorsicht nicht als sicher bezeichnet werden kann.

Das sehe ich auch als größtes Argument dagegen an. Diese globalen Formular-Variablen sind gefährlich und ausserdem führt das bei Anfängern zu einem schlechtem Stil. Bei 50 Fenstern hört sich das gar nicht gut an, wenn ich da irgendetwas zu sagen hätte würde ich versuchen, es dieser Person auszutreiben, wenn da an meinem Quelltext rumgefuchtelt wird :stupid:
Gibt meiner Meinung nach keine Vorteile, deshalb lieber gleich richtig machen und auf saubere Strukturen setzen, ist auch irgendwie mehr OOP finde ich.

[Hansa]

Zitat:

Zitat von wicht (Beitrag 1043179)

...Diese globalen Formular-Variablen sind gefährlich...

Deshalb ja meine Meinung : es gilt, zumindest die Gefahr etwas zu entschärfen. Läuft ein Programm von 8:00 bis 20:00 dann könnte das eng werden. Eventuell wird da immer einunddieselbe Form immer geöffnet und geschlossen. Im FormShow/FormClose für Ordnung zu sorgen, das ist ja schön. Allerdings : mit Vriablen meine ich jetzt nicht nur integer. Wenn z.B. eine TStringlist gebraucht wird, dann muss die erzeugt werden. Nach meiner Erfahrung ist es da besser, notfalls einen Runtime-Error zu provozieren, um ihn dann zu beseitigen, anstatt Wochen/Monate zu warten, um die gewisse Stelle dann nach Reklamation lokalisieren zu müssen.

[himitsu]

Nja, für alle, welche ihre Daten in der GUI halten, ist sowas nunmal ein gängiger Weg, wenn alles immer existiert, da sonst ja die Daten verschwinden würden. :stupid:

[hanspeter]

Meine bisherige Praxis sah eigentlich in Kurzform so aus.

Delphi-Quellcode:

With TWorkform.Create(nil) do
begin
  Init(Parameterliste);
  Showmodal;
  Free;
end;

In der Initroutine werden Comboboxen, Listen u.s.w. initialisiert.
Dieser Teil ist jetzt in das Formcreate bei Programmstart gewandert.
Das sollte , gerade in Client-Server Systemen, den Effekt haben, das bei Datenänderungen ein Neustart des Programmes notwendig ist.
Mit dem obigen Aufruf würde ein schließen und wieder öffnen des Fensters ausreichen.

Gruß

[himitsu]

Wenn, dann bitte so:

Delphi-Quellcode:

with TWorkform.Create(Parameterliste) do
  try
    ShowModal;
  finally
    Free;
  end;

[Chemiker]

Hallo,

ich bevorzuge eigentlich die Variante, dass sich das Form selber erstellt und auch selber wieder freigibt. Finde hat den Vorteil das der Aufruf immer gleich ist und die Änderungen sich nur an einer Stelle befinden.

Bis bald Chemiker