Wie sicher ist wm_copydata

[norwegen60]

Es geht mir nicht darum, dass unberechtigte die Daten lesen. Es sind reine Messwerte und sie sind unkritisch.
Ich muss aber sicherstellen, dass sie auch immer ankommen.
Um sie eindeutig zuornen zu können, habe ich dem Fensternamen eine 5stellige Nummer angehängt und die wird auch mit CopyDataStruct.dwData übergeben.
Es sollte also ziemlich sicher sein, dass ich nur Messdaten auswerte die für das Fenster bestimmt sind.

Und wozu das Ganze:
Es gibt eine Hauptanwendung, die normalerweise mit einem Messgerät verbunden ist.
Jetzt kann es aber sein, dass eine Hilfsanwendung auch mit demselben Messgerät kommunizieren muss.

1. Wenn die Hauptanwendung gestartet wird und die Hilfsanwendung schon mit dem Messgerät verbunden ist, breche ich den Start ab und sage das die Hilfsanwendung erst beendet werden muss.
2. Wenn die Hilfsanwendung gestartet wird und die Hauptanwendung schon mit dem Messgerät verbunden ist, kommuniziere ich über die Messages mit der Hauptanwendung. Wenn zulässig gibt die die Befehle ans Messgerät weiter und wieder zurück.
3. Wenn nur die Hilfsanwendung gestartet wird, verbindet die sich direkt mit dem Messgerät.

Da die Hauptanwendung incl. Kommunikation per (mehrerer DLL's) zum Messgerät schon lange existiert, wollte ich den Eingriff dort so klein wie möglich halten.
Die komplette Werteübergabe erfolgt schon seit Jahrzehnten per Strings.

Und es sieht gut aus. Erste Tests laufen bisher problemlos.

In einer anderen Anwendung arbeite ich seit Jahren mit CreateNamedPipe und ConnectNamedPipe. Da kam es aber immer wieder vor, dass ich bei Windows-Versions-Wechseln was anpassen musste. Auch gibt es hin und wieder aufhänger die ich bisher nicht nachvollziehen konnte. Von daher wollte ich das hier vemeiden.

[himitsu]

Bei PostMessage ist es schwerer zu erkennen, aber SendMessage sagt dir ja, ob es angekommen/verarbeitet wurde.
(nja, ob das Programm intern die Message verwirft, das bekommst nur mit, wenn dort dann auch ein entsprechender Result-Wert gesetzt wird)

Es muß nur jemand die Rückgabe(n) auswerten, also das was im MSDN unter "Return value" und "Remarks" erwähnt wird.

[venice2]

Zitat:

Um sie eindeutig zuornen zu können

Ob du diese eindeutig zuornen kannst weiß ich nicht
Aber wenn du diese eindeutig zuordnen willst würde ich eine Konstante in Erwägung ziehen dieser einen aussagekräftigen Namen verpassen
damit du auch in 10 Jahren noch weist wofür diese steht.

WM_COPYDATA ist sicher hatte noch nie irgendwelche Probleme diesbezüglich.
Der Vorteil zudem ist das man unabhängig ist und sogar zwischen 32 und 64Bit Anwendungen kommunizieren kann.

[TurboMagic]

Zitat von himitsu:

Bei PostMessage ist es schwerer zu erkennen, aber SendMessage sagt dir ja, ob es angekommen/verarbeitet wurde.
(nja, ob das Programm intern die Message verwirft, das bekommst nur mit, wenn dort dann auch ein entsprechender Result-Wert gesetzt wird)

Es muß nur jemand die Rückgabe(n) auswerten, also das was im MSDN unter "Return value" und "Remarks" erwähnt wird.

Nur: SendMessage wartet, bis der Empfänger die Botschaft verarbeitet hat.
Falls das empfangende Programm aber irgendwie in eine Endlosschleife geraten sein sollte
wäre dann auch der Sender blockiert, was vermutlich nicht gewünscht wäre...
Es gibt halt selten Vorteile ohne Nachteile.
Man könnte natürlich auch noch eine Verbindung in die gegenrichtugn aufbauen über die bestätigungsmeldungen gesendet werden
und jedem Datenpaket eine eindeutige ID geben... Das könnte man dann Asynchron aufbauen.

Grüße
TurboMagic

[himitsu]

Du hast ja die Qual der Wahl, wobei nur EINWAS ewig wartet (außer es läuft im selben Thread, wie das Ziel).

PostMessage
PostThreadMessage

SendMessage
SendMessageTimeout
SendMessageCallback **
SendNotifyMessage

Und neben WM_COPYDATA gibt es auch noch Anderes, um Daten zu übergeben.
WM_SETTEXT/SendTextMessage und drüben in einem unsichtbaren Windows auf WM_SETTEXT reagieren. (nur die #0000 darf da nicht vorkommen, aber dafür gibt es ja Lösungen)

[TurboMagic]

Ah, danke für die neueren Sendmessage Varianten, die kannte ich noch nicht!

[peterbelow]

Zitat von TurboMagic:

Nur: SendMessage wartet, bis der Empfänger die Botschaft verarbeitet hat.
Falls das empfangende Programm aber irgendwie in eine Endlosschleife geraten sein sollte
wäre dann auch der Sender blockiert, was vermutlich nicht gewünscht wäre...

Deshalb sollte man auch SendMessageTimeout verwenden wenn der Addressat in einem anderen Prozess lebt...

[himitsu]

Oder SendMessageCallback, falls man das Ergebnis braucht, aber nicht warten möchte,
oder SendNotifyMessage, was so ähnlich wie PostMessage nicht auf die Ausführung wartet.

Beim SendNotifyMessage weiß ich jetzt aber nicht, ob es nur auf das Ende nicht wartet, aber vielleicht darauf, ob die Verarbeitung anfängt.
Das wäre von Interesse, falls schon vorher eine andere Message dort hängt.
Im Delphi z.B. der Fall, wenn eine Exception in einer vorherrigen Message auftrag, wo jene Message erst beendet wird, wenn jemand den Fehlerdialog schießt.