Auf Task warten ohne zu bremsen

[lxo]

Hallo,

ich hab mir eine Klasse geschrieben in der ich einen Task(Thread) starte und dann dort warte bis dieser fertig ist.
Hintergrund ist der, ich möchte ein InfoForm anzeigen während der Aktion damit der User sieht das es etwas passiert und das Programm sich nicht aufgehängt hat.

Aktuelle mache ich das so:

Delphi-Quellcode:

      lInfoFormTask := TInfoFormTask.Create( nil,
                                             TNotifyEvent( nil),
                                             lProc,
                                             TThreadPool.Default,
                                             nil);

      lTask := lInfoFormTask.Start as IInfoFormTask;
      TSpinWait.SpinUntil( function: Boolean
                           begin
                             //OutputDebugString( PWideChar(DateTimeToStr( Now)));
                             Application.ProcessMessages;
                             Result := lTask.IsComplete;
                           end);
//      while not ( lTask.IsComplete) do
//      begin
//        //OutputDebugString( PWideChar(DateTimeToStr( Now)));
//        TThread.Sleep( 1);
//        Application.ProcessMessages;
//      end;

Entweder mit dem SpinWait oder der whileschleife warte ich bis der Task abgeschlossen ist.
Funktioniert auch an sich, aber die Aktion dauert dadurch deutlich länger als sie eigentlich brauch.

Wenn ich nun die Maus auf der Titelleiste des InfoForms gedrückt halte.
Geht es aufeinmal deutlich schneller.
Mit Hilfe von "OutputDebugString( PWideChar(DateTimeToStr( Now)))" konnte ich dann auch erkennen das die Anwendung gar nicht mehr in meiner "Warteschleife" läuft.

Meine Frage ist jetzt was macht Delphi/Windows beim halten des Mausklicks auf der Titelleiste, dass mein Task ungebremst weiterlaufen kann.
Oder was habe ich für eine alternative mit meiner "Warteschleife"? Ich möchte einfach warten bis der Task abgeschlossen ist und dann soll es weiter gehen.

[himitsu]

was: Wie beim ShowMessage ist innerhalb des Klicks eine "eigene" MessageLoop, welche innerhalb des Hauptthreads (in der startenden Message) aufgerufen wird.
Darin werden so lannge alle eintreffenden Messages verarbeitet (so lange, bis das Verschieben fertig ist),
aber da es dort "stoppt" und der ursprüngliche Aufruf so lange nicht abgeschlossen wird, und somit auch die MessageLoop der VCL nicht mehr aufgerufen wird (außer jemand macht HandleMessage bzw. ProcessMessages), wird aller sonstiger Code darin nicht mehr ausgeführt ... das betrifft z.B. die Behandlung von ShortCuts oder Application.OnMessage

[lxo]

Zitat:

Zitat von himitsu (Beitrag 1522837)

was: Wie beim ShowMessage ist innerhalb des Klicks eine "eigene" MessageLoop, welche innerhalb des Hauptthreads (in der startenden Message) aufgerufen wird.
Darin werden so lannge alle eintreffenden Messages verarbeitet (so lange, bis das Verschieben fertig ist),
aber da es dort "stoppt" und der ursprüngliche Aufruf so lange nicht abgeschlossen wird, und somit auch die MessageLoop der VCL nicht mehr aufgerufen wird (außer jemand macht HandleMessage bzw. ProcessMessages), wird aller sonstiger Code darin nicht mehr ausgeführt ... das betrifft z.B. die Behandlung von ShortCuts oder Application.OnMessage

Wo finde ich denn diese "eigene Messageloop" könnte doch theoretisch dann genau das machen während ich auf meinen Task warte.
Genauso wie Loop läuft bis das verschieben fertig ist.

[Uwe Raabe]

Das Auslagern in einen Thread/Task und blockierendes Warten auf dessen Ende ist doch irgendwie kontraproduktiv und in der Regel eher schädlich als hilfreich.

Lass doch die Task einfach laufen und prüfe z.B. in einem Timer ob sie schon fertig ist. Währenddessen disable alle Benutzereingaben, die dabei nicht ausgeführt werden können/sollen.

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1522840)

und prüfe

Oder sich informieren lassen.

Zitat:

Zitat von lxo (Beitrag 1522838)

Wo finde ich denn diese "eigene Messageloop"

Im Windows :stupid:

Der Grund ist einfach nur, dass DU zu häufig das

Delphi-Quellcode:

Application.ProcessMessages;

ausführst
und somit du selber die Bremse bist, weil du zusätzlich unnötig viel Code ausführen lässt.

Delphi-Quellcode:

procedure TForm4.Button1Click(Sender: TObject);
begin
  var C := GetTickCount;
  for var i := 0 to 10000 do
    Label1.Caption := i.ToString;
  Label1.Caption := (GetTickCount - C).ToString;
end;

procedure TForm4.Button2Click(Sender: TObject);
begin
  var C := GetTickCount;
  for var i := 0 to 10000 do begin
    Label1.Caption := i.ToString;
    Application.ProcessMessages;
  end;
  Label1.Caption := (GetTickCount - C).ToString;
end;

procedure TForm4.Button3Click(Sender: TObject);
begin
  var C := GetTickCount;
  for var i := 0 to 10000 do begin  // Kommentar siehe nachfolgend
    Label1.Caption := i.ToString;
    if i mod 500 = 0 then
      Application.ProcessMessages;
  end;
  Label1.Caption := (GetTickCount - C).ToString;
end;

Ein statisches Intervall ist natürlich echt blöd, weil was ist, wenn irgendwas anderes bremst, es auf einem anderen Rechner langsamer/schneller arbeitet?
Also besser eine zeitliche Abhängigkeit, wie z.B. alle 100-250 oder 1000 Millisekunden

Delphi-Quellcode:

var C := GetTickCount;
for var i := 0 to 10000 do begin  // Kommentar siehe nachfolgend
  Label1.Caption := i.ToString;
  if GetTickCount - C > 250 then begin
    Application.ProcessMessages;
    C := GetTickCount;
  end;
end;

Es gibt auch Anbderes zum Messen und man beachte, dass im aktuellen Delphi 11 nun auch noch standardmäßig die Überlaufprüfung aktiv ist (falls Windows mal mehr als 47 Tage lang durch läuft).

[hoika]

Hallo,
such hier mal nach "semimodal".
Damit geht das in Deinem speziellen Fall auch, ohne Performance zu verlieren.

[Der schöne Günther]

Wenn man sich nicht schämt das direkt auf dem Formular zu machen:

Delphi-Quellcode:

unit GUI.MainForm;

interface uses
   System.SysUtils,
   System.Classes,
   System.Threading,

   Vcl.Graphics,
   Vcl.Controls,
   Vcl.Forms,
   Vcl.Dialogs,
   Vcl.StdCtrls;

type
   TMainForm = class(TForm)
      Button1: TButton;
      Label1: TLabel;
      procedure Button1Click(Sender: TObject);
   private var
      myTask: ITask;
      waitingForm: TForm;
   private
      procedure someWork();
      procedure signalCompletion();
   end;

var
   MainForm: TMainForm;

implementation

{$R *.dfm}

procedure TMainForm.Button1Click(Sender: TObject);
begin
   myTask := TTask.Run(someWork);
   waitingForm := TForm.Create(self);
   waitingForm.ShowModal();
end;

procedure TMainForm.signalCompletion();
begin
   waitingForm.ModalResult := mrClose;
end;

procedure TMainForm.someWork();
begin
   TThread.Sleep(2000);
   TThread.Queue(TThread.Current, signalCompletion);
end;

end.

PS: Freigabe des Popups nicht vergessen.

[freejay]

Also ich würde überhaupt nicht auf das Ende des Threads warten sondern als letzte Aktion in dem Thread einfach eine Event-/Callback-Prozedur aufrufen. Oder spricht da was dagegen?

[lxo]

Zitat:

Zitat von freejay (Beitrag 1522930)

Also ich würde überhaupt nicht auf das Ende des Threads warten sondern als letzte Aktion in dem Thread einfach eine Event-/Callback-Prozedur aufrufen. Oder spricht da was dagegen?

Jetzt mache Ich es genau so. Klappt wunderbar.
Da ich eh ein InfoForm Modal öffne ist alles weiter im Hintergrund blockiert und am Ende des Threads wird das Form einfach geschlossen.

Danke für eure Anregungen und Tipps.

Habe bisher nicht ganz so viel mit Threads gearbeitet aber so langsam machts immer mehr Klick und schafft auch viele neue Ideen und Lösungen.