TMessageManager/SendMessage

[TurboMagic]

Zitat:

Zitat von TiGü (Beitrag 1454857)

Um nochmal sicher zu gehen - weil ich hier eine Wissenslücke vermute - wenn du TTask.Run() schreibst, machst du einen Thread auf (bzw. benutzt einen vorhandenen Workerthread) der UNGLEICH des Mainthreads ist.

Wenn du darin Dinge tust, wie zum Beispiel den TMessageManager zu benutzen, der dann für die jeweilige Message die angemeldete Callback/Event-Methode aufruft und in der auf visuelle Komponenten zugegriffen werden, dann ist das falsch!

Der TMessageManager ist kein abgekoppeltes Gelumpe wie die Windows PostMessage-Funktion.
Das ist ein ganz schnödes Observer-Pattern.
Du musst als Benutzer/Client dafür sorgen, dass alles in seinen richtigen Threadkontext passiert.

Genau das wollte ich mit meienr Antwort oben, dass TMessageManager synchron arbeitet, ausdrücken!
Wer's anders umgesetzt haben will suche meinen QP feature request und stimme für diesen.

=> synchronisieren wie empfohlen und schon wird's klappen

[TigerLilly]

Zitat:

Der TMessageManager ist kein abgekoppeltes Gelumpe wie die Windows PostMessage-Funktion.
Das ist ein ganz schnödes Observer-Pattern.

Ja, das stimmt, das hab ich übersehen. Danke dafür.

[TigerLilly]

:- ) Jetzt tut das so, wie ich will - danke für alle Hinweise.

Im Formular im FormCreate, um das UI zu aktualisieren:

Code:

  MessageManager := TMessageManager.DefaultManager;
  SubscriptionId := MessageManager.SubscribeToMessage(TMessage<UnicodeString>,
    procedure(const Sender: TObject; const M: TMessage)
    begin
      lblStatus.Text := (M as TMessage<UnicodeString>).Value;
    end);

Eine Methode, die länger braucht, wird so aufgerufen:

Code:

    TTask.Run(procedure()
    begin
      LoadXML(dlgOpenXML.FileName);
    end);

Im LoadXML wird die Info für das Aktualisieren des UI so versandt:

Code:

    TThread.Queue(nil,procedure
    begin
         TMessageManager.DefaultManager.SendMessage(nil, TMessage<UnicodeString>.Create(LTxt) );
    end);

[Uwe Raabe]

Zitat:

Zitat von TurboMagic (Beitrag 1454914)

Wer's anders umgesetzt haben will suche meinen QP feature request und stimme für diesen.

Wenn ich ihn finden würde, dann würde ich dagegen stimmen! Ein ähnlicher Feature-Request (RSP-17054) ist gleich am nächsten Tag vom Poster selbst wieder zurückgezogen worden. Die Begründung würde ich auch so führen.

[TurboMagic]

Zitat:

Zitat von Uwe Raabe (Beitrag 1454947)

Zitat:

Zitat von TurboMagic (Beitrag 1454914)

Wer's anders umgesetzt haben will suche meinen QP feature request und stimme für diesen.

Wenn ich ihn finden würde, dann würde ich dagegen stimmen! Ein ähnlicher Feature-Request (RSP-17054) ist gleich am nächsten Tag vom Poster selbst wieder zurückgezogen worden. Die Begründung würde ich auch so führen.

Ich nicht ;-)
Ich kann mir auch Szenarien vorstellen, wo eine Message nicht vom Main Thread aus verschickt wird, und der OP bestätigt das ja,
sonst hätte es den gesammten Thread nicht gegeben. Ich würde einfach asynchron wie PostMessage unter Windows aber eben
plattformübergreifend Nachrichten versenden können wollen.

Man kann ja auch eine synchrone Variante beibehalten, so wie es in Windows ja auch PostMessage gibt.

[TigerLilly]

Unter FMX funktioniert das ganze Aktualisieren des UI anders als unter VCL. Gleichzeitig ist "UI aktualisieren" etwas sehr zentrales, das jede/r braucht. Daher hat es mich gewundert, das es nichts out-of-the-box gibt. Und dass man selber mit Threads und Queues herumtun muss. Eine Komponente würds ja schon tun, die das kapselt, was man so zu Fuß machen muss.

[Uwe Raabe]

Zitat:

Zitat von TigerLilly (Beitrag 1454984)

Unter FMX funktioniert das ganze Aktualisieren des UI anders als unter VCL. Gleichzeitig ist "UI aktualisieren" etwas sehr zentrales, das jede/r braucht. Daher hat es mich gewundert, das es nichts out-of-the-box gibt. Und dass man selber mit Threads und Queues herumtun muss.

Die Anzahl der Aufrufe von Application.ProcessMessages im FMX-Code fördern nicht gerade mein Vertrauen in eine mögliche Standard-Implementierung.

Es ist oft viel einfacher, eine Lösung für den eigenen, konkreten Anwendungsfall zu implementieren, als eine allumfassende Lösung, die allen nur möglichen Szenarien Rechnung trägt. Selbst wenn da jemand wäre, der das entwerfen könnte, wären nicht ausreichend Leute vorhanden, um das zu pflegen. Vermutlich wäre es dann auch wieder so komplex, daß es kaum einer versteht - mit der Folge, daß doch wieder jeder seinen eigenen Brei kochen würde.

Ist der Wunsch danach auch nachvollziehbar, wären die meisten wohl vom Ergebnis ziemlich enttäuscht.