"Unendlicher Progressbar"

[himitsu]

KEINE VCL im Thread benutzen.

Wenn, dann als NonVCL direkt mit CreateWindow, CreateDialog oder Dergleichen.

[jaenicke]

Du darfst aus dem Thread nicht unsynchronsiert auf das Formular zugreifen.

Du könntest allerdings einen Dialog hiermit verwenden:
https://github.com/jaenicke/MTCL
Der funktioniert im Thread unabhängig von anderen Threads.

An solch einer Komponentensammlung scheint nicht wirklich Interesse zu bestehen, so dass ich diese auch nicht mehr weiterentwickelt habe, zumindest öffentlich. Aber das Prinzip funktioniert.

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1469203)

Du darfst aus dem Thread nicht unsynchronsiert auf das Formular zugreifen.

Richtig! Allerdings funktioniert synchronisiert zugreifen auch nicht, da der Hauptthread ja beschäftigt ist.

Besser wäre es, den SplashScreen im HauptThread als erstes zu erzeugen und anzuzeigen und regelmäßig bei jeder abgeschlossenen Aufgabe den Texteintrag zu aktualisieren. Threads würde ich da komplett außen vor lassen.

[Benmik]

Wenn ich das richtig verstanden habe, dann ist doch der MainThread ein VCL-Thread, der pausenlos läuft und auf Nachrichten wartet. Wenn ich jetzt alle Arbeiten in separate Threads verlege, dann müsste doch der MainThread frei sein und alle Anzeigen verzögerungsfrei und nicht blockierend verarbeiten. Es müsste also theoretisch alles ganz einfach sein. Tatsächlich klappt das auch, aber schwierig wird es, wenn man Application.ProcessMessages vermeiden will. Ich bringe ohne z.B. einen Timer unter AsyncCalls nicht zum Laufen. Und die Einarbeitung in die OTL ist schwieriger als gedacht, und bisher ist AsyncCalls auch schneller.

[Uwe Raabe]

Zitat:

Zitat von Benmik (Beitrag 1469216)

Es müsste also theoretisch alles ganz einfach sein.

Theoretisch - ja. Trotzdem ist es in den meisten Fällen besser auf Threads ganz zu verzichten. Insbesondere wo es - wie in diesem Fall - um Arbeiten mit VCL-Komponenten geht.

[skoschke]

So, nun habe ich einen Versuch ohne Thread gestartet:

Soll der Splashscreen angezeigt werden, mache ich ein (bisher unsichtbares) Panel sichtbar und setze seine Caption.
Danach läuft die Lange Erzeugungs-Routine.

Lasse ich das Programm laufen, ist das Panel sichtbar, aber die Caption fehlt!
Die kommt erst wenn die lange Routine fertig ist....
Ein Panel.Repaint, Refresh, etc. hat da nichts verbessert, das kann doch nicht so schwer sein, ich beiße langsam in die Tischkante!

Ciao
Stefan

[himitsu]

Repaint, ProgessMessages oder Dergleichen ... wurde alles schonmal genannt, auch das Warum.

[stahli]

Wenn das Holen der Daten 90% der Zeit braucht und das Erzeugen und füllen der Controls 10%, dann könnte es Sinn machen, das Holen der Daten in einen Thread auszulagern.

Der einzige Vorteil wäre allerdings, dass die Anwendung reaktiv bleibt und irgendein Pinökel da irgendwie rumrödeln kann.
Im Ergebnis hätte man eine Rödel-Anzeige und irgendwann - schwupps - werden die Controls erzeugt.

Das macht u.U. deutlich Mehraufwand und kann auch Probleme erzeugen, wenn man die Synchronisation nicht korrekt regelt.


Diese 90:10-Verteilung würde ich aber im genannten Beispiel nicht erwarten.
Insofern würde ich es wie Uwe machen und z.B. in einer Statusbar oder Splash-Formular kurze Zwischenstände anzeigen.

1/10 ... Daten werden gesammelt (ca. 2 min, also heute bis ca. 18:02 Uhr)
2/10 ... alles wird vorbereitet (ca. 5 min, also heute bis ca. 18:07 Uhr)
...
10/10 ... ferdisch (hat 2 h gedauert)

[himitsu]

Diese Pinökel würde aber auch verhinder dass Windows daherkommt, von wegen "Programm reagiert nicht" und das Programm womöglich abgeschossen wird. (egal ob jetzt mit Thread oder regelmäßigem Refresh)

[Uwe Raabe]

Ein Panel.Update nach dem Setzen von Panel.Caption sollte aber funktionieren.