FMX + UI aktualisieren

[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

[Der schöne Günther]

Zitat von Mavarik:

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

Nein, wenn du ein Anzeige-Element hast das den Fortschritt aus 10 Threads anzeigt sitzt darauf ein Timer. Und den musst du auch nicht starten und stoppen, der kann ruhig immer laufen. Das kostet doch nichts.

Nehmen wir als Beispiel einen Download-Manager der zehn Dateien gleichzeitig herunterlädt. Da ändere ich doch nicht den Code für das Herunterladen um anzupassen wie schnell die Anzeige auf einem Formular aktualisiert werden soll indem ich weniger Status-Updates triggere.

Klar gehört in die Anzeige keine Logik. Aber du wirst ja auf dem Formular auch nicht mit irgendwelchen Sperr/Synchronisations-Mechanismen hantieren sondern da sitzt doch sicher irgendeinen Mittelsmann dazwischen die nur die Aufgabe hat zu sagen was grade abgearbeitet wird und wie der Fortschritt ist. Timer -> OnTimer -> viewModel.updateProgress(); .

[philipp.hofmann]

In meiner Anwendung läuft eine Uhr mit, daher habe ich eh einen Timer am Laufen und dieser updated bei Bedarf dann auch weitere Elemente der Anzeige. Wenn man so etwas wie diese Uhr nicht hat, mag der Timer ineffektiv sein. So ist es die einfachste und übersichtlichste Lösung.

[Mavarik]

Zitat von Der schöne Günther:

Nein, wenn du ein Anzeige-Element hast das den Fortschritt aus 10 Threads anzeigt sitzt darauf ein Timer. Und den musst du auch nicht starten und stoppen, der kann ruhig immer laufen. Das kostet doch nichts.

Und wenn ich neben dem gesamt download den Fortschritt aller einzelnen Threads anzeigen möchte?
Dann ggf. noch eine Uhr, eine Statusanzeige die anzeigt, dass die Datenbank sich mit der Cloud synchronisiert.
Die Aktien chart, die upgedatet werden muss, uvm.
Und warum soll ich permanent einen Timer laufen lassen der immer wieder in einer Queue nachschaut, wenn es (wie mein Beispiel (#8) gezeigt habe) viel einfacher geht?
Ich möchte keinen Timer haben der immer läuft - schon gar nicht, wenn er permanent in einer Queue nachschauen muss die jedes mal hierfür ein locking durchführen muss.
Auf einem 5GHz PC mag das egal sein, aber sicherlich nicht in einer App die auf Batteriestrom läuft (z.B. Mobil-Device/Smartwatch).

Zitat von Rollo62:

Der Timer kann zu ungenau sein für eine Uhr.
Für eine Uhr würde ich immer die Systemzeit nehmen, z.B. mit Now();, und diese dann z.B. mit dem Timer (oder anders) aktualisiert anzeigen.

Ich denke so hat er das gemeint.