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