Zitat von LTE5:

Mich intertessiert aber trotzdem noch wie man so einen Thread aufweckt und schlafen legt.
Und wie man auf Terminate reagiert und ob man in WaitFor festhängt.
Und woher kommt das Ergebnis von FEvent.WaitFor? Muss man das von Außen setzen?

Also:

Der Thread "schläft" im WaitFor(TimeOut) für TimeOut ms. Ich sage mal in dieser Zeit wird "NULL" CPU-Zeit verbraucht.

Aufgeweckt wird der Thread entweder wenn TimeOut aufgetreten ist oder wenn mit SetEvent der Event gesetzt wird (extern oder ggf. im Destructor)

Also bei einem FThreadTimer.Free rufst Du im destructor Setevent auf, damit die Execute procedure aus dem Waitfor raus kommt und gut ist es.

Gibt da noch einen alten Post von mir für einen "normalen" Thread...

Mavarik

Zitat:

Der Thread "schläft" im WaitFor(TimeOut) für TimeOut ms. Ich sage mal in dieser Zeit wird "NULL" CPU-Zeit verbraucht.

Aufgeweckt wird der Thread entweder wenn TimeOut aufgetreten ist oder wenn mit SetEvent der Event gesetzt wird (extern oder ggf. im Destructor)

Also bei einem FThreadTimer.Free rufst Du im destructor Setevent auf, damit die Execute procedure aus dem Waitfor raus kommt und gut ist es.

Das hat geholfen!

Das bedeutet zwangsweise, dass ein langes Warten bei einem Sleep umgangen wird wenn der Thread beendet wird.

Zitat von LTE5:

Das bedeutet zwangsweise, dass ein langes Warten bei einem Sleep umgangen wird wenn der Thread beendet wird.

Naja den Thread wird man ja nicht beenden, hat ja sicherlich einen Sinn, sondern eher das Programm!

markieren

Delphi-Quellcode:

procedure TNormalThread.Execute;
begin
 Sleep(60000);
end;

Angenommen ich würde mein Programm nun beenden. Dann müsste ich noch so lange warten, bis Sleep() vorbei ist.
Mit den Events habe ich das jetzt so verstanden, dass das WaitFor unterbrochen wird, sobald ich das Signal dazu an den Thread schicke (z.B. im OnClose).

Zitat von LTE5:

markieren

Delphi-Quellcode:

procedure TNormalThread.Execute;
begin
 Sleep(60000);
end;

Angenommen ich würde mein Programm nun beenden. Dann müsste ich noch so lange warten, bis Sleep() vorbei ist.
Mit den Events habe ich das jetzt so verstanden, dass das WaitFor unterbrochen wird, sobald ich das Signal dazu an den Thread schicke (z.B. im OnClose).

Richtig!

100 Gummipunkte für meinen Hohlkopf!

Leider -200 Gummipunkte für mich. Ich glaube ich bin zu dämlich dafür die Ableitung aus Beitrag 2 zu nutzen

markieren

Delphi-Quellcode:

var TestThread: TTestThread;

procedure TForm1.Button2Click(Sender: TObject);
begin
 TestThread:= TestThread.Create;
 TestThread.Interval := 60000;
end;

zusammenfalten · markieren

Delphi-Quellcode:

unit Unit3;

interface

uses
 System.Classes, System.Classes, System.SyncObjs, uCustomThread, Dialogs;

type
 TTestThread = class(TCustomThread) // TCustomThread ist die Unit aus Beitrag 2
 private
  {Private-Deklarationen}
 protected
  procedure Execute; override;
 end;

implementation

{TTestThread}

procedure TTestThread.Execute;
var
 res: TWaitResult;
begin
 while not Terminated do
  begin
   // Sleep(1000);
   res := FEvent.WaitFor(FInterval); // also z.B. 1000

   // An FEvent komme ich nicht dran. An FInterval natürlich auch nicht. Nur die Frage ist wieso.

   // if 1 = 2 then
   // viel zu tun
   // end;
   case res of
    wrSignaled:
     TThread.Synchronize(nil,
       procedure
      begin
       showmessage('Signaled');
      end);
    wrTimeout:
     ;
    wrAbandoned:
     Terminate;
    wrError: {Fehler loggen}
     ;
   end;
  end;
end;

end.

Du musst
executeTimed überschreiben.

Eigentlich sollte der Compiler meckern da Execute als final deklariert ist

Damit das mit dem Event auch klappt, habe ich folgende Zeile in der Hauptunit (Beitrag 2) eingefügt. Ansonsten kann ich Event in einer Ableitung nicht sehen.

markieren

Delphi-Quellcode:

public
 property Event: TEvent read FEvent write FEvent;

ExecuteTimed also. Ok. Ich habe währenddessen ein bisschen rumprobiert um zu sehen wie der Thread reagiert je nachdem was ich mache.
Mit dem Event-Property funktioniert dann auch das hier

zusammenfalten · markieren

Delphi-Quellcode:

procedure TTestThread.ExecuteTimed;
var
 res: TWaitResult;
begin
 while not Terminated do
  begin
   res := Event.WaitFor(Interval); // also z.B. 1000

   case res of
    wrSignaled:
     TThread.Synchronize(nil,
       procedure
      begin
       showmessage('Signaled'); // Wird beispielsweise aufgerufen, wenn ich außen <Thread-Instanz>.Terminate; ausführe
      end);
    wrTimeout:
     TThread.Synchronize(nil,
      procedure
      begin
       showmessage('Timeout'); // Wird immer aufgerufen, wenn oben das WaitFor vorbei ist AUßER es gab vorher wrSignaled, wrAbandoned oder wrError.
      end);
    wrAbandoned:
     Terminate;
    wrError: {Fehler loggen}
     ;
   end;
  end;

 TThread.Synchronize(nil,
  procedure
  begin
   showmessage('Thread Ende');
  end);
end;

Was genau wrSignaled macht habe ich aber noch nicht herausgefunden.

jetzt hast du 2 mal eine Schleife die auf Terminated wartet.
Im execute und im ExecuteTimed.
Vergiss doch einfach den Event im ExecuteTimed, oder noch besser versuche zu verstehen was Deine ThreadKlasse wirklich macht....