"Unendlicher Progressbar"

[stahli]

Korrekter Weise kannst Du die langwierige Aufgabe nur in einen Thread auslagern und die Darstellung durch eine Schleife im Hauptthread aktualisieren.

Mit Application.ProcessMessages kannst Du den Effekt zwar auch erreichen, aber das ist eher unsauber und kann u.U. zu Problemen führen.

[skoschke]

Die langwierige Aufgabe ist die Erzeugung von Komponenten und das Laden von denen mit Inhalt.

Irgendwie sehe ich da Probleme das in einen Thread auszulagern?
Da müsste der Thread ja im MainForm Konmponenten erzeugen und füllen, macht man so etwas?

Ciao
Stefan

[himitsu]

Wenn man im Hautthread arbeiten muß,
dann muß man eben selber regelmäßig für eine Aktualisierung der GUI sorgen, da sie währeddessen ja keine Zeit bekommt.

* Form.Repaint bzw. Komponente.Repaint (Achtung, Windows sieht hier dennoch die Form nach einer Weile als "hängend" an)
* Application.ProgressMessages; (aufpassen, da hier alle Messages verarbeitet werden ... nicht dass da zwischendrin "unpassende" Aktionen starten)
* * z.B. Nutzer klickt nochmal auf den Button (dann läuft das mehrmals ineinanderverschachtelt)
* wir haben und mal ein eigenes "ProgressMessages" gebaut, was nur gewisse Messages ausführt (Windows-HangUp-Erkennung, Zeichenaktionen usw., aber keine Timer-, Maus oder Tastaturereignisse)

* viele machen das in einer Schleife alle X Durchläufe (unschön, da PCs nicht immer gleich schnell sind)
* ich mach es zeitabhängig, also in der schleife prüfen wann das letzte Mal und dann alle X Millisekunden (z.B. 100/200/250/500/1000ms ... je nach Anwendungsfall)



OK, das Erstellen/Freigeben von Komponenten muß in dem Thread erfolgen, wo die Form erstellt wurde und behandelt wird.

Füllen kann man manche Komponenten aber auch im Thread.
* oftmals gibt es eine BeginUpdate-Methode, welche die Komponente von der automatischen Aktualisierung sperrt
* und wenn beim Update des Inhaltes nicht auf globale Objekte zugegriffen wird, die noch von anderswo in Verwendung sind,
* * dann kann man BeginUpdate und EndUpdate im Hauptthread ausführen und den Rest dazwischen auslagern

[stahli]

Ok, das wird in einem Thread schlecht gehen (außer Daten zu sammeln und zu puffern, um die Controls dann in einem Rutsch erzeugen zu können).

Um welche Zeitspannen handelt es sich denn?

Ggf. wäre einfach ein statischer Splashscreen sinnvoller, der auf die mögliche Zeitspanne hinweist. Dann müssen keine Klimmzüge gemacht werden, damit ein grüner Balken hin und her zuckelt, was ohnehin nicht wirklich hilfreich ist.

Welche Workarounds man gehen könnte, hängt sicherlich von den genauen Umständen ab.

[Uwe Raabe]

Selbst mit Application.ProcessMessages wird der Progressbar merklich ruckeln, wenn man das nicht weniger als alle 50 ms macht. Etwas genügsamer ist ein TActivityIndicator, aber auch der kommt nicht ohne Application.ProcessMessages aus.

Zitat von skoschke:

Die langwierige Aufgabe ist die Erzeugung von Komponenten und das Laden von denen mit Inhalt.

Da würde ich eher ansetzen. Ist es wirklich das Erzeugen der Komponenten oder das Laden der Inhalte, was soviel Zeit kostet?

[Benmik]

Zitat von himitsu:

Application.ProgressMessages; (aufpassen, da hier alle Messages verarbeitet werden ... nicht dass da zwischendrin "unpassende" Aktionen starten)

Was ist mit dieser Antwort von dir höchstpersönlich?

[Uwe Raabe]

Sowohl die TProgressBar im Marquee-Mode als auch der TActivityInidicator arbeiten timer-basiert. Simples Invalidate/Update/Repaint funktioniert da leider nicht.

Ich plädiere für ein simples Bitte warten... Fenster oder ein Splash-Form ohne viel Drumherum.

[bcvs]

Ich mache so etwas hiermit:
http://www.delphifaq.com/faq/f382.shtml

[Benmik]

Zitat von Uwe Raabe:

Ich plädiere für ein simples Bitte warten... Fenster oder ein Splash-Form ohne viel Drumherum.

Als Anwender finde ich das nicht so gut. Bei länger dauernden Prozessen fragt sich der Anwender ja immer, ob das Programm nicht hängt, was es nicht selten ja wirklich tut. Zum anderen möchte er irgendeine Information. Ich zeige immer die Anzahl der Verarbeitungen an. Oft hat der Anwender eine Vorstellung davon, wieviele das ungefähr sind (zum Beispiel von vorangegangenen Läufen). Dann hat er auch mehr Chancen zu merken, wenn etwas nicht stimmt. Nichts ist schlimmer als minutenlang auf "Bitte warten..." oder eine Animation zu gucken und keine Ahnung zu haben, ob es sinnvoll ist, noch weiter zu warten.

[Uwe Raabe]

Man kann auf dem Splash-Screen ja auch den aktuellen Bearbeitungsfortschritt als Text in einem Label darstellen. Das reagiert dann in der Regel auch auf ein Refresh.