FormCreate für alle Forms beim Start aufrufen

[alzaimar]

Zitat:

Der Unterschied ist, daß Application eben unnötig ist. Mr. Green Ich benutze das nur, um z.B. etwas in der Taskleiste anzeigen zu lassen, ein Icon zu setzen usw.

Das ist so falsch: Wenn ich über Application.CreateForm gehe, dann sorgt eben die Application dafür, das beim Programmende die Forms ordendlich und sauber abgebaut werden: Also erst alle Messages zu Ende abarbeiten, dann dichtmachen, dann Speicher freigeben etc. Wenn ich die Forms einfach so kreiere und dann wieder wegschmeisse, dann kann es sein, das irgendwo was nicht ganz sauber abgebaut wird.

Jetzt zum Thema: Wenn ich Forms mit Datensensitiven Steuerelementen bei Programmstart erzeuge, dann klingen sich alle TDBEdits und TDBGrids etc. in eine Notifier-Liste ein, die vom Dataset immer reium benachrichtigt wird, wenn sich was in der DB ändert: Deshalb heissen sie ja auch so : datensensitive Steuerelemente.

Mein Tipp: Wie auch die der Vorredner: Erzeuge jeweils nur die unbedingt notwendigen Forms. Weil Forms manchmal etwas Zeit zum kreieren benötigen, ist as manchmal doch angebracht, sie vorher zu erzeugen. Sonst wartet der Benutzer unnötigerweise.

Ich mach es so:

Delphi-Quellcode:

If Not Assigned (fForm) Then
  Application.CreateForm (TfForm, fForm);

Wobei ich schön drauf achte, das alle Form-Variablen beim Programmanfang mit nil initialisiert werden. Das ist bei W2K zwar egal, aber bei dem W95/ME Schrott kann/konnte man sich da nicht sicher sein. Aber gute Programme initialisieren sowieso Alles und Jeden!

[Hansa]

Das ist ja schön und gut, aber erzähle auch noch, wie man das Ganze selber wieder freigeben kann, bzw. wie die Forms wieder dazu gezwungen werden, ihre Variablen etc. neu zu initialisieren. Ich bin z.B. jamand, der alle Forms mindestens einmal aufmacht. Was dann ?

[alzaimar]

Ich implementiere immer eine Methode TForm.Setup, die das Formular initialisiert, die edits leert, Variablen zurücksetzt und das Formular in einen definierten Anfangszustand versetzt (ActiveControl etc.). Dann rufe ich das Formular nicht einfach über ShowModal auf, sondern schreibe mir eine kleine Routine, die das macht. Das ist auf den ersten Blick etwas umständlich, aber ich finde, Anweisungen sollten da stehen, wo sie hingehören.

Delphi-Quellcode:

Function EditKunden (aKunde : TKunde) : TModalResult;
...
Implementation
...
Function EditKunden (aKunde : TKunde) : TModalResult;
Begin
  If Not Assigned (fmEditKunde) Then Application.CreateForm (TfmKunde, fmKunde);
  With fmKunde Do Begin
    Setup (aKunde);
    // hier passiert vielleicht noch mehr...
     Result := ShowModal;
     End;
End;

Wieso muss der Aufrufer wissen, das man das Formular mit Setup initialisieren muss? Eben deshalb schreibe ich diese 'EditXXXX' Funktionen. Allerdings mache ich es i.A. nicht über Application.CreateForm. Ich hatte neulich mal eine Ausnahme: Das Formular zum Bearbeiten eines Auftrags enthielt ettliche Grids, Edits, Lookuplisten etc. Das Erzeugen (mit Create) und das Initialisieren dauert 500-900ms: zu lang für ein Callcenter. Also wurde dieses eine Formular wie oben beschrieben, erzeugt.

Meine Edits sehen so aus:

Delphi-Quellcode:

Function EditKunden (aKunde : TKunde) : TModalResult;
...
Implementation
...
Function EditKunden (aKunde : TKunde) : TModalResult;
Begin
  With TfmEditKunde.Create (Nil) Do Begin
    Setup (aKunde);
    // hier passiert vielleicht noch mehr...
     Result := ShowModal;
     Release; // Kein Free, weil nur Release garantiert, das vorher die message queue geleert wird.
     End;
End;

Damit ist das Formular immer in einem wohldefinierten Zustand, ich verbrate keine Resourcen, falls auf dem Formular TDBEdits sind, geht meine Performance nicht in die Knie, usw. Das Wichtigste ist aber (frei nach Sepp Herberger):

Zitat:

Nach dem Aufruf ist vor dem Aufruf

[Hansa]

Das ist alles schon sehr seltsam, was Du da machst. Inwiefern beeinträchtigen DBEdits die performance ? Und das bei der Erstellung eines Formulars ? :shock: Ist mir echt zu hoch. Vermutlich liegt ein prinzipieller Fehler im Design vor, z.B. Datenabankabfragen in der Setup-Prozedur. Jedenfalls kann ich das Verhalten nicht bestätigen. Form mit 4-seitigem PageControl, ca. 100 DBEdits, etliche Listboxen usw. Von Ladezeiten ist da weit und breit nichts zu bemerken.

Ansonsten hast Du lediglich die Initialisierungsgeschichten in extra Prozedur verlagert, machst vieles von Hand und kannst somit aber auch mal was vergessen. Deine EXE wird mit Sicherheit größer sein, als meine. :mrgreen:

Anweisungen sollten natürlich da stehen, wo sie hingehören. Und das heißt eben : Initialisierungen direkt beim Erzeugen, also in OnCreate und Freigabe in OnClose und ohne extra Aufruf von irgendwas. Ein CloseAction := caFree; reicht völlig aus.

[Sharky]

Zitat:

Zitat von Hansa

... Deine EXE wird mit Sicherheit größer sein, als meine.....

Zitat:

Zitat von Hansa

... Im Zeitalter von 1 GB RAM sehe ich darin aber keine wichtige Begründung, ....

Hmmm... die Echse soll so klein wie möglich sein aber der RAM Verbrauch ist nicht so wichtig? Das ist für mich eine sehr seltsame Philosophi.

Ich finde das Konzept von alzaimar durch vernünftig. Es gibt einen Aufruf für das Fenster. Der rest wird intern geregelt.

[Hansa]

Hai Sharky,

Zitat:

Zitat von Hansa

Delphi-Quellcode:

frm := TFrm.Create(self);

procedure Tfrm.FormClose(Sender: TObject;
  var Action: TCloseAction);
begin
  Action := caFree;
end;

Wohl übersehen ? Wenn es noch kürzer/kompakter gehen sollte, dann sage wie. Da ist kein if und wenn und aber. 8) Alles wird im OnCreate geregelt. Die Freigabe übernimmt komplett Delphi.

[alzaimar]

Warum TDBEdits die Performance runterziehen?

Zitat:

Jetzt zum Thema: Wenn ich Forms mit datensensitiven Steuerelementen bei Programmstart erzeuge, dann klinken sich alle TDBEdits und TDBGrids etc. in eine Notifier-Liste ein, die vom Dataset immer reium benachrichtigt wird, wenn sich was in der DB ändert: Deshalb heissen sie ja auch so : datensensitive Steuerelemente.

Stand in meinem vorherigen Posting.

Mit anderen Worten: Wenn Du in deiner Anwendung den Inhalt eines TDatasets änderst, werden ALLE TDBEdits benachrichtigt, egal ob sie sichtbar sind oder nicht. Deine beim Programmstart erzeugten Formulare habe alle eine Messagequeue, müssen alle mit Nachrichten versorgt werden und reagieren auch alle auf Nachrichten. Also wenn das keine Performancebremse ist...

Zitat:

Deine EXE wird mit Sicherheit größer sein, als meine.....

Das erinnert mich an das vergleichen der Größe der primären Geschlechtsmerkmale bei Pubertierenden. Da lassen wir uns aber nicht drauf ein und sagen: JA! Meine Echse ist größer! Ätsch!

Die Größe von EXEn ist mir Schnurz. Wichtig ist, das ich in 10 Jahren das Zeugs noch kapiere, es anständig und stabil läuft und wartbar ist. Dann kommt die Performance. Und, erst wenn alles hübsch sauber ist, feile ich noch an der EXE-Größe, abern nur aus kosmetischen Gründen. Nebenbei arbeite ich mit DevEx-Componenten, da sind die Exen von Hause aus bei 4-8 MB angesiedelt.

Ich kann in meinem Create keine Initialisierungen reinmachen, die abhängig von dem sind, *WAS* ich gerade editieren will. Wenn ich also ein Formular für die Bearbeitung eines TKunden habe, wie und wo soll ich denn die Edits mit dem TKunden initialisieren?