TMessageManager/SendMessage

[TigerLilly]

FMX, nicht VCL.

Ich greife ja nicht im gliechen Kontext auf den Label zu. Ich habe einen Task, der tut was und versendet Messages.
Mein MainThread ist derweil im Leerlauf und arbeitet die messages ab. Synchronize braucht es da nicht.

PS: Eigentlich wollte ich auf diesen Thread verlinken:
https://www.delphipraxis.net/202388-...alisieren.html

[TiGü]

Zitat von TigerLilly:

FMX, nicht VCL.

Ich greife ja nicht im gliechen Kontext auf den Label zu. Ich habe einen Task, der tut was und versendet Messages.
Mein MainThread ist derweil im Leerlauf und arbeitet die messages ab. Synchronize braucht es da nicht.

PS: Eigentlich wollte ich auf diesen Thread verlinken:
https://www.delphipraxis.net/202388-...alisieren.html

FMX oder VCL spielt keine Rolle, für beide gelten die gleichen Regeln.

Wenn dem so ist, wie du glaubst und behauptest, dann könntest du ja einfach meine If-Abfrage mit der EProgrammerNotFound-Exception einfügen.
Wenn die Exception kommt, dann hast du einen Denkfehler und musst das einfach umsetzen, was dir schon empfohlen wurde.
Wenn die Exception nicht kommt, dann enthältst du uns Informationen vor, die dir zwar klar sein mögen, aber uns aufgrund des Nichtvorhandenseins des Quelltextes der Funktion LoadXML() nicht ersichtlich sind.

PS: Im neuen verlinkten Thread wird von Mavarik in der Methode TForm319.UpdateUI auch mithilfe von TThread.Queue() aus dem Thread-Kontexts des Tasks heraus in den Mainthread synchronisiert.

[TiGü]

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.

[Rollo62]

Delphi-Quellcode:

  // in TTask.Run
  // 

  ...
  LTxt := xNode.Text;

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

   ...

[TurboMagic]

Zitat von TiGü:

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 von TurboMagic:

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 von Uwe Raabe:

Zitat von TurboMagic:

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.