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