Programm komplett laden, schnell anzeigen aber nicht von Events abhängig sein?

[günni0]

Der Titel ist etwas doof gewählt aber es ist im Prinzip einfach erklärt.

Ganz grob nur... und stark vereinfacht.

- aller Code zum Initalisieren des Programms in FormCreate
Vorteil: alles ist da, wo es nicht wirklich schaden anrichtet
Nachteil: bis das Programm angezeigt wird dauert es eventuell länger

- (viel) Code.... in WmFormVisible
Vorteil: Programm ist schnell sichtbar, weil weniger in FormShow oder FormCreate ist
Nachteil: man ist davon abhängig, dass das Formmular mindestens 1x sichtbar ist, damit alles geladen wird

Gibt es da eine Art Zwischenlösung, womit man aus beiden Punkten etwas Gutes hat und so wenig wie möglich Nachteile?

Beispiel für etwas, was ich aktuell in FormShow mache, was sonst nirgendwo anders möglich ist: Position und Größe des Hauptformulars setzen.
Etwas was ich in FormCreate erledige: Sprache des Hauptformulars laden, Programmeinstellungen laden, Caption setzen, Variablen initialisieren.

[KodeZwerg]

Binde das in {$SetPEFlags IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP or IMAGE_FILE_NET_RUN_FROM_SWAP} unter Uses ein und Dein Programm liegt komplett im Arbeitsspeicher, das sollte alles beschleunigen *theoretisch (!)*
Das Laden wiederum verlängert sich da nun alles in Speicher geladen wird.

[p80286]

Zitat von günni0:

Vorteil: alles ist da, wo es nicht wirklich schaden anrichtet

ungewöhnliche Formulierung

Zitat von günni0:

Nachteil: bis das Programm angezeigt wird dauert es eventuell länger

Man könnte ein Bild/Form anzeigen lassen und im Hintergrund durch ein oder zwei Threads die Initialisierungen Durchführen lassen.

Gruß
K-H

[Aviator]

Alles was mit der GUI zusammenhängt muss logischerweise auch dort gemacht werden. Wenn du natürlich erst die Sprachpakete/Dateien von der Festplatte laden musst, dann kannst du den Teil evtl. noch in einen externen Thread auslagern. Die Umstellung der Captions passiert aber weiterhin im MainThread. Genau so wie das Setzen der Position.

Wenn du bspw. Daten bereits zu Beginn aus einer Datenbank lädst, dann kannst du auch das in einen externen Thread packen.


Grundsätzlich sollte man eigentlich alle Aktionen die länger als eine gewisse Zeit in Anspruch nehmen in einen Thread auslagern. Dass das nicht immer möglich ist bzw. sehr viel Aufwand bedeutet weiß ich. Ich mache auch nicht jede Kleinigkeit in einem Thread. Aber gerade wenn es um Datenbankabfragen geht die etwas länger dauern können, wird das durchaus ausgelagert.

Die Bedienbarkeit deines Programmes kannst du eigentlich auch nur dann gewährleisten, wenn der MainThread/GUIThread nur für die GUI zuständig ist und alles was mit dem abholen, verändern oder speichern von Daten zu tun hat in einem eigenen, vom MainThread unabhängigen, eigenen Thread erledigst.

[freimatz]

Zitat von günni0:

- aller Code zum Initalisieren des Programms in FormCreate

Definitv nein.
Aller Code zum Initalisieren einer Form in dessen FormCreate, aber Code zum Initalisieren des Programms woanders hin

[hoika]

Hallo,
ich nehme immer FormActivate,
dann sieht er Nutzer zumindestens, dass was passiert.

Bei langsamem Aufbau (kann ja auch mal sein, langsame DB oder so) ev. noch ein "Bitte warten"-Fenster.

Und da manchmal FormActivate mehrfach aufgerufen wird, kommt als erstes ein

OnActivate:= nil;

rein

[haentschman]

Moin...

Zitat:

Bei langsamem Aufbau (kann ja auch mal sein, langsame DB oder so) ev. noch ein "Bitte warten"-Fenster.

Im OnActivate Datenbankzugriffe ausführen zu lassen oder Datenmengen zu laden... Das kann ggf. nach hinten losgehen.

Zitat:

Mit OnActivate können Sie bestimmte Operationen durchführen, sobald das Formular den Fokus erhält (wenn beispielsweise der Benutzer darauf klickt).

...das ist nicht immer gewollt.

[jaenicke]

Unsere Struktur sieht grob so aus:

Delphi-Quellcode:

  if TXyz.ExecuteCommandline then
    Exit;
  Application.Initialize;
  try
    TXyz.Startup;
    try
      Application.MainFormOnTaskbar := True;
      Application.CreateForm(..., ...);
      Application.Run;
    finally
      TXyz.Shutdown;
    end;
  except
    on E: Exception do
    begin
      ...
    end;
  end;

Das Hauptformular registriert sich selbst mit einem interfacebasierten Wrapperobjekt als Anzeige. Ein Splashscreen wird bereits vorher durch eine der ersten eingebundenen Units angezeigt.

Das kann man natürlich auf viele Arten machen, aber das Grundprinzip ist, dass der Programmablauf nichts mit der Anzeige zu tun hat, sondern diese lediglich angesprochen wird (und umgekehrt die Anzeige lediglich Interfaces abruft um Events an die Businesslogik weiterzugeben usw.).

[Mavarik]

SplashScreen?

[Aviator]

Zitat von Mavarik:

SplashScreen?

Ist das eine Frage oder eher eine Aussage wie "Sowas macht man noch?".

Falls es eine Frage ist hilft das hier vielleicht.