Aktualisierung und SendMessage

[yogie]

Hallo zusammen,

ich beobachte folgenden Sachverhalt:

Von einer ersten Form (TDataModule) übertrage ich per SendMessage Daten zu einer anderen Form und lasse dort ein Element (z.B. Edit) aktualisieren. Sobald ich die Form verschiebe wird die Aktualisierung unterbrochen und läuft erst weiter wenn ich die Verschiebung beende. Mir ist schon klar, dass es an der Unterbrechung der Message-Loop liegt, aber eine richtig befriedigende Erklärung habe ich nicht. Weiterhin habe ich den Eindruck, dieses Verhalten ist nicht bei allen Objekten gleich und ich meine es hängt auch noch vom Betriebssystem ab (das geht jetzt zurück bis WIN95).

In der realen Anwendung soll die erste Form (TDataModule) Informationen über eine serielle Schnittstelle empfangen und sie dann an verschiedene Formen in der Anwendung verteilen. Bisher hatte ich dazu direkte Aufrufe von Prozeduren verwendet. Aus Gründen der besseren Trennung zwischen serieller Schnittstelle und div. Anzeigen wollte ich das jetzt ändern.

Ich wäre dankbar für eine Erklärung oder einen Tipp wie man es besser machen könnte.

[jaenicke]

Ich würde die Kommunikation asynchron per Thread machen und die graphische Aktualisierung synchronisieren. Das funktioniert auch beim Verschieben eines Fensters problemlos, zumindest unter Windows 8. Testbeispiel von mir eben (nicht schön, nur zum Test):

Delphi-Quellcode:

type
  TTest = class(TThread)
  protected
    procedure Execute; override;
  end;

  TForm18 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form18: TForm18;

implementation

{$R *.dfm}

procedure TForm18.Button1Click(Sender: TObject);
begin
  TTest.Create(False);
end;

{ TTest }

procedure TTest.Execute;
begin
  while not Terminated do
  begin
    TThread.Synchronize(nil, procedure
      begin
        Form18.Canvas.LineTo(Random(Form18.ClientWidth), Random(Form18.ClientHeight));
      end);
    Sleep(100);
  end;
end;

[yogie]

@jaenicke

Danke erstmal für den Tip.

Zwei Dinge dazu
- kann es sein, dass im Beispiel die Zeilen im Execute etwas durcheinander geraten sind?
so kann ich es jedenfalls in Delphi6 nicht machen,
ich habe es dann etwas umgebaut und zum Laufen gebracht ...

- das Problem mit der hängenden Aktualisierung läßt sich damit prima umgehen
mir geht es aber zusätzlich um eine Entkopplung zwischen der Empfänger-Form für
die seriellen Daten und den anderen Fenstern, die die Anzeigen machen.
ich habe in der Empfängerform zur Zeit eine Liste (TList) in der ich alle Anzeigefenster speichere,
bei neu einlaufenden Daten gehe ich diese Liste durch und schicke allen sichbaren Fenstern
die neuen Daten (SendMessage)

Ich habe festgestellt, dass SendMessage recht zeitaufwendig ist. Daher suche ich eine bessere
Lösung

[jaenicke]

Zitat von yogie:

- kann es sein, dass im Beispiel die Zeilen im Execute etwas durcheinander geraten sind?
so kann ich es jedenfalls in Delphi6 nicht machen,

Stimmt, anonyme Methoden gibt es erst ab Delphi 2009.

Zitat von yogie:

mir geht es aber zusätzlich um eine Entkopplung zwischen der Empfänger-Form für
die seriellen Daten und den anderen Fenstern, die die Anzeigen machen.
ich habe in der Empfängerform zur Zeit eine Liste (TList) in der ich alle Anzeigefenster speichere,

Genau dafür kannst du das nutzen. Du kannst dem Thread Bescheid geben und der verteilt die Aktualisierungen asynchron weiter an die weiteren Anzeigen.

[Medium]

Zitat von yogie:

Ich habe festgestellt, dass SendMessage recht zeitaufwendig ist. Daher suche ich eine bessere
Lösung

SendMessage() ist nicht per se langsam, sondern es wartet auf das Ende der vom Empfänger durchgeführten Aktion. Das asynchrone äquivalent dazu ist PostMessage() - das wartet nicht.

[jaenicke]

Nur als Hinweis, falls es relevant sein sollte: PostMessage geht nur, wenn man die Daten nach dem Abschicken nicht wieder freigibt, da die Abarbeitung später passiert.

Eine Trennung der Steuerung der GUI von der Datenverwaltung und auch der einzelnen Fenster untereinander hielte ich aber für sinnvoller als ein Fenster direkt mit den anderen Fenstern via Messages kommunizieren zu lassen.

[Furtbichler]

Wir hatten mal eine ähnliche Anwendung. Dort sind Daten von Messgeräten eingetroffen, sollten in die DB und parallel dazu angezeigt werden.

Wir haben es mit Threads und Messages (PostMessage) ausprobiert. Beides funktioniert gleich gut. In meinem Hinterkopf trällert aber immer noch, das man nicht mit Threads nicht um sich werfen sollte. Das kann ein Überbleibsel aus der der Steinzeit sein, aber ich finde Threads hierfür einfach oversized.

Ich würde zunächst das Observer-Pattern einführen, um Datenempfang und Visualisierung auch logisch zu entkoppeln und skalierbar zu machen.

Der Datenempfang implementiert einen Observer, an dem sich Formulare, die Daten anzeigen wollen, anmelden können.
Die Observerbenachrichtigungsschleife ist als Job eines Workerthreads implementiert, der wiederum eine Jobliste (=Queue) abarbeitet. So kann dieser Workerthread (besser : Pool) beliebige Jobs abarbeiten und das System kommt auch bei kurzzeitiger Überlastung nicht ins Schwitzen. Selbst wenn kurzzeitig sehr viele Benachrichtungen anstehen, blockiert der Observer nicht, da dann eben die Jobliste etwas voll wird...

Die Benachrichtigung an die einzelnen Subscriber (=Forms) kann nun als Postmessage verschickt werden. Das ist imho leichtgewichtiger als noch einen Thread zu starten. Allerdings sind dabei die Einschränkungen von Sebastian zu beachten. Man kann hier die Daten z.B. in eine Datenklasse mit Referenzzählung wrappen (Stichwort: Interface) oder Strings verwenden (z.B. bei einem Logger), der die Referenzzählung auch eingebaut hat.

Das generelle Problem ist hier, das bei Überlastung die Messagequeue der einzelnen Subscriber zu voll werden könnte. Das muss man im Einzelnen bewerten, ob das eine Rolle spielt und wie man damit umgehen kann bzw. soll.