Hallo Zusammen,

ich habe ein Testprojekt angehängt.
In diesem Projekt sendet und empfängt die Anwendung BROADCAST Nachrichten in einer Anwendung!

Die Test-Anwendung scheint so weit zu funktioniert und macht auch scheinbar keine Probleme da sie auch kaum Funktionalität beinhaltet. Integriere ich es jedoch in meiner Anwendung kommt es vor dass die Anwendung spürbar langsamer wird. Auch habe ich den Effekt dass wenn eine Nachricht gesendet wird und Thunderbird im Hintergrund aktiv ist, wird Thunderbird in den Vordergrund gezogen. Warum Thunderbird, keine Ahnung.

Die gesamte Technik habe ich in der Form BroatcastSenderReceiver.pas gesteckt. Ich binde die Form ein der MainForm ein und registriere einen Event.

Ich habe es in eine separate Form extrahiert und nicht in ein DataModul da SendMessage ein Form handle benötigt.

Das Ziel ist eigentlich, eine Datenbank-Anwendung wird auf einem Rechner zweimal gestartet, und läuft jeweils auf einem Monitor, wird auch so benötigt. Wenn die Anwendung A einen Datensatz ändert, soll die Anwendung B ein refresh durchführen wenn zufällig der gleiche Datensatz angezeigt wird. Als Datenbank verwende ich Firebird. Ich habe auch die Events benutzt die Firebird und Firedac anbietet, doch es gab fälle da hat es eben nicht zuverlässig funktioniert. Deshalb versuche ich jetzt selbst über BROADCAST Nachrichten.

Ich habe leider keine Erfahrung mit Windows messaging. Was zuverlässig funktionieren würde wäre eine TCP Kommunikation. Für eine einfache Benachrichtigung wollte ich eben keinen Listener aufsetzen. Möglicherweise sollte ich keine BROADCAST Nachricht senden sondern nur eine bestimmte registrieren, aber wie gesagt, da habe ich keine Erfahrung damit.

Möglicherweise ist jemand dabei der Erfahrung mit Windows messaging hat und kann mir an den angehängten Projekt zeigen was nicht in Ordnung ist.

Mit HWND_BROADCAST in deinem Code

SendMessage(HWND_BROADCAST, WM_COPYDATA, Integer(Handle), Integer(@copyDataStruct)) ; sendest du deine Nachricht ja gleich an alle Apps (auch deinem Thunderbird). Es genügt, wenn du die Nachricht von deiner App A an deine App B (und umgekehrt) sendest.

A benötigt dazu ein Handle HANDLE_B von B und umgekehrt B eines von A. In App A sendest du dann SendMessage(HANDLE_B,....)

Beispiele gibt's viele:
https://www.thoughtco.com/send-infor...ations-1058476

Du musst daran denken, dass SendMessage(…) erst zurückkehrt, wenn die Gegenstelle die Meldung quittiert hat. Vielleicht willst du dies - eventuell aber auch nicht.

Via Sockets ist die Sache vielleicht flexibler, wenn die Apps A und B irgendwann nicht mehr auf der gleichen Kiste laufen (?).

Benutze das Broadcast doch nur einmal um die beiden Prozesse miteinander zu verbinden. Jeder Prozess sendet beim Start ein Broadcast mit seinem Handle. Der empfangende Prozess sendet sein Handle zurück und verwendet dabei als Ziel das Handle des Broadcasters. Danach sind die beiden Handles jeweils bekannt und die Prozesse können sich privat untereinander Messages zusenden, wie Michael das vorgeschlagen hat. Bei Programmende meldet sich der Prozess bei seinem Gegenüber wieder ab. Das Broadcast wird somit nur einmal bei jedem Programmstart benötigt.

Eigentlich schickt man Broadcasts nicht via SendMessage, sondern per PostMessage umher, dazumal man sowieso keine Rückgabewerte bekommen kann,
ansonsten musst du natürlich warten, bis ALLE TopLevel-Fenster fertig sind, womöglich auch mit der Fehlerbehandlung deiner "unverständlichen" Daten.

Gut, WM_COPYDATA schickt man natürlich via SendMessage an ein Programm Fenster,
und ich bin mir auch relativ sicher, dass man WM_COPYDATA eh nicht als Broadcast an ALLE versenden sollte,
und du willst nicht wissen was alles kaputt gehen kann, wenn irgendein Programm das Format deines WM_COPYDATA nicht versteht, weil es etwas Anderes erwartet.
Also siehe der Vorschlag meines Vorredners.

... oder nutze HWND_BROADCAST gar nicht.

Wenn du von App B den Namen des Fensters FB kennst, welches die WM_COPYDATA Meldungen auswerten soll, dann kannst du in App A das Handle HANDLE_B von FB mittels FinwdWindow ermitteln.

Danach sendest du deine Daten von FA nach FB mittels SendMessage( HANDLE_B, WM_COPYDATA, ... );

Etwa so:

https://www.delphipraxis.net/201045-..._copydata.html

Oder: Falls App A immer App B startet, dann kannst du beim Starten von App B als Parameter das Handle des Fensters FA übergeben. App B liest den Wert HANDLE_A via paramstr(..) aus.


Vielleicht interessiert dich in diesem Zusammenhang auch
WM_MEINEMELDUNG := RegisterWindowMessage( 'MeinePrivateMeldung' );

https://docs.microsoft.com/en-us/win...windowmessagea

Zitat:

Wenn du von App B den Namen des Fensters FB kennst

Ich hoffe du meinst den Namen der Klasse und nicht die Caption, welche eventuell Statuswerte enthalten oder eine Übersetzung.

Unter dem Punkt Interprozesskommunikation (IPC) gibt es noch unzählige weitere Möglichkeiten.
Man kann sich sogar ein unsichtbares MessageOnlyWindow (ähnlich dem Application.Handle) selbst basteln und via GetWindowLong(GWL_USERDATA) direkt einen Handle/TCPPort/Sonstwas oder eben dort geziehlt WM_COPYDATA hinsenden/abfragen.

Vielen Dank für die vielen Antworten.
Ich werde leider erste heute Abend dazu kommen mich damit zu beschäftigen.

Die Anwendung um die es geht ist eine MDI Anwendung. Da hatte ich massive Probleme das Handle zu bekommen, bzw. die Nachrichtien sind nie angekommen. Deshalb habe ich eine normale Form die zwar instantiiert jedoch nicht angezeigt wird und die Nachrichten per eigenen Event bereitstellt. Am liebsten wäre mir allerdings ein DataModul. Gibt es dafür auch eine Lösung oder muss es immer eine Form sein?

Zitat von himitsu:

Zitat:

Wenn du von App B den Namen des Fensters FB kennst

Ich hoffe du meinst den Namen der Klasse und nicht die Caption, welche eventuell Statuswerte enthalten oder eine Übersetzung.

Mir "völlig egal"* - wenn du willst auch gleich Klassenname und Windowstitel/Caption - Hauptsache ist: Der Wert muss systemweit eindeutig sein. Wenn Kostas ein unsichtbares Fenster nutzt, dann ändert Kostas wohl kaum was an der Caption.

* Ich nehme auch einen eindeutigen Klassennamen

Zitat von Kostas:

muss es immer eine Form sein?

Es kann jede beliebige Klasse sein. Man muss sie nur passend aufbereiten. Hier ein Basisgerüst:

zusammenfalten · markieren

Delphi-Quellcode:

type
  TMessageListener = class
  private
    FWindowHandle: HWND;
    procedure WndProc(var Msg: TMessage);
  public
    constructor Create;
    destructor Destroy; override;
  end;

constructor TMessageListener.Create;
begin
  inherited;
  FWindowHandle := AllocateHWnd(WndProc);
end;

destructor TMessageListener.Destroy;
begin
  if FWindowHandle <> 0 then
  begin
    DeallocateHWnd(FWindowHandle);
    FWindowHandle := 0;
  end;
  inherited;
end;

procedure TMessageListener.WndProc(var Msg: TMessage);
begin
  Msg.Result := DefWindowProc(FWindowHandle, Msg.Msg, Msg.wParam, Msg.lParam);
end;

Hallo Uwe,

deinen Vorschlag mit der eigenen Klasse würde ich gerne umsetzen.

Ich habe folgenden Zustand: die gleichen source werden über zwei unterschiedliche .dpr Dateien kompiliert. Somit habe ich eine Eingang.exe und eine Ausgang.exe Die Anwendung selbst ist eine MDI-Anwendung. Ich könnte also eine zwei Klassen haben z.B.: TMessageListernerE und eine TMessageListernerA anlegen und über die .dpr entsprechend einbinden. Mit findWindow kann ich vermutlich nur sichtbare Formklassen finden. Gibt es eine Möglichkeit wie findWindow um die zwei Klassen TMessageListernerE und TMessageListernerA die auch keine Forms sind zu finden? Dann könnte ich gleich direkt adressieren und brauchte auch kein Broadcast um das handle an Eingang zu Ausgang und umgekehrt zu übertragen.

Alternativ könnten ich wenn findWindow auch unsichtbare Forms finden könnte, auch zwei Forms Eingang und Ausgang verwenden und in der jeweiligen Projektdatei entsprechend einbinden.

Zum nächsten, möchte die Nachricht versenden und NICHT warten bis die Anwendung antwortet. Sollte ich dafür besser PostMessage anstelle von SendMessage verwenden?