Die GUI kann aber doch genauso gut auswerten, ob es gerade 1000 von 10000 Schritten sind, sie muss sich ja nicht jedes Mal aktualisieren.

@Jim, ja, Dich meinte ich.


In welcher For-Schleife?

Wenn ein Thread eine Aufgabe erledigt brauchst Du eigentlich keine For-Schleife.
Und welche Aufgabe hast Du 10.000 Mal durchführen lassen und hast Du auch die Progressbar 10.000 mal neu zeichnen lassen?

Dann lass einfach nur jeden 100. Durchgang die Progressbar aktualisieren.
Dann bist Du in 100 Schritten bei 100% und gut ist.

Willst Du mal ein kleines Demoprojekt basteln und hier anhängen?
Ich denke, das lohnt sich, weil sich das bestimmt noch etwas ordnen ließe...

Zitat:

Wenn ein Thread eine Aufgabe erledigt brauchst Du eigentlich keine For-Schleife.
Und welche Aufgabe hast Du 10.000 Mal durchführen lassen und hast Du auch die Progressbar 10.000 mal neu zeichnen lassen?

hat schon alles seine Richtigkeit, keine Sorge.
Vorher habe ich bei jedem for-Durchgang aktualisiert. Davon wollte ich nur weg und es einfacher haben.

Zitat:

Willst Du mal ein kleines Demoprojekt basteln und hier anhängen?
Ich denke, das lohnt sich, weil sich das bestimmt noch etwas ordnen ließe...

Ich versuche es mal auf die Schnelle

Hier eine kleine Demo.
Die Demo ist echt unschön gemacht zeigt aber vom PRINZIP her was ich meine.

Schaue ich mir heute Abend mal an...

Danke. Und bitte hau mich nicht dafür
Wie gesagt ist es sehr dreckig gemacht drum herum. Das Wichtige sind nur die beiden Execute-Prozeduren in beiden Threads. Der Rest (was wie wo deklariert wird) ist dreckig und unwichtig.

Und warum keine Message senden wenn es was anzuzeigen gibt?
Wenn die Oberfläche Zeit hat was anzuzeigen wird sie das auch tun, da kann man sich das ganze Polling/Timer-Zeug sparen.

Gruß
K-H

Ich wollte gerade mal ein Beispiel mit einem Event machen.
Das Projekt lässt sich aber mit meinem XE3 nicht kompilieren - bricht einfach hart ab.

Welches Delphi nutzt Du?

Hallo,

Zitat von Jim Carrey:

Und bitte hau mich nicht dafür

ich muss dich leider hauen. Die TForm1.LongDelay und vorallem deren Aufruf aus TArbeiterThread.Execute geht einfach garnicht. Wozu das unbenannte Event, welches nur in der Methode existiert? Dann wird Application.ProcessMessages aus einem Thread aufgerufen, was mitunter das Potenzial hat, die gesammte Anwendung zuzerlegen.

Wenn man in einem Thread unter ca. 20ms (siehe unten) warten will, benutzt man sleep. Will man länger warten benutzt man eines der WaitFor-Angebote vom System, unter benutzen eines Terminate-Events.

Zu den 20ms: Den genauen Wert weis ich aktuell nicht. Aber es gibt bei den WaitFor... beim TimeOut eine untere Grenze, bei deren Unterschreitung die Zeit nicht mehr eingehalten wird.

Zitat von einbeliebigername:

Hallo,

Zitat von Jim Carrey:

Und bitte hau mich nicht dafür

ich muss dich leider hauen. Die TForm1.LongDelay und vorallem deren Aufruf aus TArbeiterThread.Execute geht einfach garnicht. Wozu das unbenannte Event, welches nur in der Methode existiert? Dann wird Application.ProcessMessages aus einem Thread aufgerufen, was mitunter das Potenzial hat, die gesammte Anwendung zuzerlegen.

Wenn man in einem Thread unter ca. 20ms (siehe unten) warten will, benutzt man sleep. Will man länger warten benutzt man eines der WaitFor-Angebote vom System, unter benutzen eines Terminate-Events.

Zu den 20ms: Den genauen Wert weis ich aktuell nicht. Aber es gibt bei den WaitFor... beim TimeOut eine untere Grenze, bei deren Unterschreitung die Zeit nicht mehr eingehalten wird.

Seid nicht so hart zu mir. Ich sagte doch das war einfach nur dahin geklatsch.

Zum Thema Delay und Thread, guck mal hier: Delay von negaH

Zitat:

Welches Delphi nutzt Du?

Die Demo hab ich mit XE2 gemacht, habe aber auch XE3.

Zitat:

Und warum keine Message senden wenn es was anzuzeigen gibt?
Wenn die Oberfläche Zeit hat was anzuzeigen wird sie das auch tun, da kann man sich das ganze Polling/Timer-Zeug sparen.

Dann brauche ich den zweiten Thread aber trotzdem. Denn er wäre es ja, der die Message sendet.