FMX + UI aktualisieren

[Mavarik]

Also...

Du startest einen Thread und in diesem Thread willst Du die UI aktualisieren...

Die richtige Antwort hängt von Deiner intention ab...

1.) Willst Du unbedingt alle UI Updates zeigen: Synchronize
2.) Ist es Dir egal, ob die UI alle Zwischenwerte anzeigt: Queue

Ist Deine Statusupdate sehr schnell: Werte nur dann aktualisieren, wenn seit dem letzten update wenigsten z.B. 500ms vergangen sind prüfen und dann wieder genau wie unter 1 und 2.

Jedenfalls keinen Timer!

Mavarik

[TigerLilly]

Warum keinen Timer? Sonst brauche ich eine Schleife.

[philipp.hofmann]

Ich starte die Verarbeitung in einem Thread und habe in der UI einen Timer, der alle x ms prüft, ob in der Queue für UI-Updates etwas drinnen steht. Der Thread befüllt dann diese Queue.

[Rollo62]

Du hast TMessageManager vergessen.
Ich schicke (publish) gerne eine TMessage die mit TThread.Queue abgesichert an mein UI.
Dann braucht können sich ein oder mehrere UI's subscriben, ohne sich drum zu kümmern woher die Message kommt.

[Mavarik]

Zitat von TigerLilly:

Warum keinen Timer? Sonst brauche ich eine Schleife.

Wofür eine Schleife?

Zitat von philipp.hofmann:

Ich starte die Verarbeitung in einem Thread und habe in der UI einen Timer, der alle x ms prüft, ob in der Queue für UI-Updates etwas drinnen steht. Der Thread befüllt dann diese Queue.

Und warum willst Du die UI Task damit nerven per Timer etwas auszulesen? Du hast doch den TThread.Queue(NIL,Procedure...

Zitat von Rollo62:

Du hast TMessageManager vergessen.
Ich schicke (publish) gerne eine TMessage die mit TThread.Queue abgesichert an mein UI.
Dann braucht können sich ein oder mehrere UI's subscriben, ohne sich drum zu kümmern woher die Message kommt.

Das geht sicherlich auch - verwende ich auch gerne, wenn ich ein Multicast benötige.

Aber warum nicht einfach so:

Delphi-Quellcode:

procedure TForm319.UpdateUI(aNewValue : Integer);
begin
  TThread.Queue(NIL,Procedure
   begin
     if Assigned(Button1) then // Form Closed?
       Button1.Text := aNewValue.ToString;
   end);
end;

procedure TForm319.Button1Click(Sender: TObject);
begin
  Button1.Enabled := false;

  TTask.Run(Procedure
   var
     LastOut : TDateTime;
     i       : Integer;
  begin
    LastOut := NOW;

    for i:=0 to 600 do // 1 Min.
      begin
        sleep(100);

        if MilliSecondsBetween(LastOut,Now) > 500 then
          begin
            if not(Assigned(Button1)) then // Form Closed?
              exit;

            UpdateUI(i);
            LastOut := Now;
          end;
      end;

    if Assigned(Button1) then
      Button1.Enabled := true;
  end);
end;

[Der schöne Günther]

Ich habe auch noch nicht verstanden was gegen einen Timer spricht.

Einfacher kann ich nicht kontrollieren dass auf der Oberfläche nicht 100 mal neu gepinselt wird und sich in Wirklichkeit die Progressbar nur 2 Millimeter weiterbewegt.

Wenn ich die Klasse ändere will ich mir keine Gedanken machen müssen wer wohl an den OnChange-Events dranhängen könnte und ob ich auf den Rücksicht nehmen muss nicht "zu oft" oder "zu viele Infos" zu liefern.

Und einen Timer versteht jeder. Der muss ja auch nur nachschauen ob es was neues gibt, und das kostet keine Zeit. Und nur wenn es etwas neues gibt, dann muss ich in meiner Oberfläche etwas pinseln.

[Mavarik]

Zitat von Der schöne Günther:

Ich habe auch noch nicht verstanden was gegen einen Timer spricht.

Einfacher kann ich nicht kontrollieren dass auf der Oberfläche nicht 100 mal neu gepinselt wird und sich in Wirklichkeit die Progressbar nur 2 Millimeter weiterbewegt.

Wenn ich die Klasse ändere will ich mir keine Gedanken machen müssen wer wohl an den OnChange-Events dranhängen könnte und ob ich auf den Rücksicht nehmen muss nicht "zu oft" oder "zu viele Infos" zu liefern.

Und einen Timer versteht jeder. Der muss ja auch nur nachschauen ob es was neues gibt, und das kostet keine Zeit. Und nur wenn es etwas neues gibt, dann muss ich in meiner Oberfläche etwas pinseln.

Ich will nicht, das meine UI permanent nachschauen muss... Abgesehen davon muss ich dann eine Queue nehmen die das Threadsafe Locking macht - wofür?

Ich will auch nicht für jedes Update aus einen Thread nen dummen Timer habe, den ich jeden smal vorher starten und nach der Verarbeitung wieder anhalten muss.

ggf. Habe ich 10 Thread die etwas machen - soll ich dafür 10 Timer nehmen, 10 Queues erzeugen und alles per TMonitor sperren?

Mein Form/View ist Dumm und hat so wenig code wie möglich den ich pflegen muss... Ich will das mein UI schneller aktualisiert wird - kein Thema dann mache ich die Einstellungen da wo ich weis was Sache ist und nicht in der View(Form).

Klar ist mein Beispiel in einem Button-Click aber das war auch nur dafür, dass man es schnell mal testen kann... Sowas kommt in einen andere Unit.

Mavarik