TMessageManager/SendMessage

[TigerLilly]

Ich habe in meinem Formular dieses, um Messages zu empfangen + als Status ausgeben zu können:

Delphi-Quellcode:

 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:

Delphi-Quellcode:

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

Im LoadXML wird so der Status versandt:
Die Nachricht wird so versandt:

Delphi-Quellcode:

    TMessageManager.DefaultManager.SendMessage(nil, TMessage<UnicodeString>.Create(xNode.Text), True);

Das führt aber nach ein paar 100 Nachrichten zu einer Zugriffsverletzung. Übersehe ich da etwas?

[TurboMagic]

1. Zugriffsverletzung an welcher Stelle?

2. Soweit mir bekannt arbeitet dieses Messagjng synchron,
wenn du also im Empfangsevent der Nachricht mit GUI
Controls interagierst und die Message von einem Thread
verschickt wurde muss es Mal knallen.

[TigerLilly]

Die Zugriffsverletzung entsteht irgendwo in der RTL bei den Threads. Ohne Sender Message läuft das ohne Probleme.

In einem anderen Thread
https://www.delphipraxis.net/202390-...alisieren.html

wurde dieses Vorgehen vorgeschlagen. :shock:

[TiGü]

Delphi-Quellcode:

 MessageManager := TMessageManager.DefaultManager;
  SubscriptionId := MessageManager.SubscribeToMessage(TMessage<UnicodeString>,
    procedure(const Sender: TObject; const M: TMessage)
    begin
      if TThread.Current.ThreadID <> MainThreadID then
        raise EProgrammerNotFound.Create('Ich komme aus dem Thread-Kontext des Tasks, also muss ich den Zugriff auf das Label lblStatus im Mainthread synchronisieren!');

      lblStatus.Text := (M as TMessage<UnicodeString>).Value;
    end);

[TigerLilly]

Das heisst, das Problem ist, dass ich hier auch auf Messages reagiere, die gar nicht von mit selber komen?

Ich müsste also TMessage<TnurVonMirString> registrieren und alles ist gut?

[TiGü]

Nein, dass ist die völlig falsche Schlussfolgerung.

Du hast einen Workerthread, in dessen Kontext die Task ausgeführt wird.
Innerhalb dieses Kontextes greifst du auf ein VCL-TLabel zu.
Auf VCL-Komponenten darf nur innerhalb des Mainthreads zugegriffen werden.
Das weißt du, dass wird hier auch an jeder Ecke oft erklärt.
In dem von dir verlinkten Thread hast du die richtige Vorgehensweise mit TThread.Synchronize schon drin, einfach wieder mit übernehmen.

[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:

Zitat von TigerLilly (Beitrag 1454855)

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. :roll:

[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:

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.