Code vom Thread in einen Timer umziehen?

[DeddyH]

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

[stahli]

@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...

[Jim Carrey]

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

[Jim Carrey]

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

[stahli]

Schaue ich mir heute Abend mal an...

[Jim Carrey]

Danke. Und bitte hau mich nicht dafür :stupid:
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.

[p80286]

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

[stahli]

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?

[einbeliebigername]

Hallo,

Zitat:

Zitat von Jim Carrey (Beitrag 1352005)

Und bitte hau mich nicht dafür :stupid:

ich muss dich leider hauen. Die

Delphi-Quellcode:

TForm1.LongDelay

und vorallem deren Aufruf aus

Delphi-Quellcode:

TArbeiterThread.Execute

geht einfach garnicht. Wozu das unbenannte Event, welches nur in der Methode existiert? Dann wird

Delphi-Quellcode:

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.

[Jim Carrey]

Zitat:

Zitat von einbeliebigername (Beitrag 1352012)

Hallo,

Zitat:

Zitat von Jim Carrey (Beitrag 1352005)

Und bitte hau mich nicht dafür :stupid:

ich muss dich leider hauen. Die

Delphi-Quellcode:

TForm1.LongDelay

und vorallem deren Aufruf aus

Delphi-Quellcode:

TArbeiterThread.Execute

geht einfach garnicht. Wozu das unbenannte Event, welches nur in der Methode existiert? Dann wird

Delphi-Quellcode:

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.

[stahli]

So würde ich es machen (XE3)...

Mit Events ist es noch besser strukturiert als mit Übergabe des Formulars.
Nachrichten verschicken ginge natürlich auch, aber das habe ich schon Jahre nicht mehr gemacht. :oops:

[Jim Carrey]

Bedrohung blockiert
Objekt: delphipraxis.net/attachments/....
Infektion:
Win32:Evo-gen [Susp]

:stupid:

Sieht aber interessant aus. Wusste ich gar nicht, dass das überhaupt so möglich ist.
Edit: da steht zwar "0x aufgerufen" aber ich habs runtergeladen und angeguckt.

[einbeliebigername]

Zitat:

Zitat von Jim Carrey (Beitrag 1352014)

Ich sagte doch das war einfach nur dahin geklatsch.

Manches geht aber auch dahingeklatsch nicht. Und manchmal sind die einfacheren Lösungen die besseren.

Zitat:

Zitat von Jim Carrey (Beitrag 1352014)

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

Da steht was von wegen mit eigener Messagequeue. Du hast aber kein Thread mit Messagequeue. Ich hab noch nie einen Thread mit eigener Messagequeue unter den Fingern gehabt bzw. selbst gebaut. Bin aber, bis mich jemand vom gegenteil überzeugt, der Meinung das so ein Thread seinen eigenen Nachrichtenverarbeitungscode haben sollte.

Edit: Fehlendes [/QUOTE] eingefühgt.

[Jim Carrey]

Ist zwar offTopic aber... in Threads dann doch besser ein simples Sleep() verwenden?

[stahli]

Ich hatte noch das FreeOnTerminate vergessen, so dass der Thread nach Beendigung nicht freigegeben wurde:

Delphi-Quellcode:

constructor TArbeiterThread.Create(aMinValue, aMaxValue: Integer; aProgressInitEvent: TProgressInitEvent;
  aProgressStepEvent: TProgressStepEvent; aProgressCloseEvent: TProgressCloseEvent);
begin
  fMinValue := aMinValue;
  fMaxValue := aMaxValue;
  fProgressInitEvent := aProgressInitEvent;
  fProgressStepEvent := aProgressStepEvent;
  fProgressCloseEvent := aProgressCloseEvent;

  FreeOnTerminate := True; // <------------

  inherited Create(False);
end;

Ja, ein Sleep(1 oder höher) im Thread gibt anderen Prozessen auch mal die Möglichkeit, etwas auszuführen.
Sleep(0) prinzipiell auch, aber ich hatte dennoch schon den Effekt, dass die CPU mit 100% weiter lief.

[Jim Carrey]

Ich habe irgendwann angefangen negaH's Version zu verwenden, weil ich zu oft Fehler gemacht habe.
Mein letzter war eine while-Schleife im OnCreate etwa wie...

Delphi-Quellcode:

while True do Caption := IntToStr(Random(1234));

Das hat mir den Rechner fast zerlegt. Seitdem benutzte ich immer die Version mit ProcessMessages als Sicherung.