Luckie hat folgendes geschrieben :

Ich weiß nicht, was ihr für ein Problem mit WM_COPYDATA habt.

Das erkläre ich dir gern. WM_COPYDATA ist low-evel, platformabhängig, proprietär (das Datenformat) und architektonisch aus der Steinzeit. Mit WM_COPYDATA kannst du vielleicht schnell ein record mit Integers und ShortStrings (non-Unicode) rüberschicken. Sobald es etwas weiter gehen soll und du z. B. Request-Reponse haben willst, schreibst du erst mal ein eigenes Protokoll, ein eigenes Message Format und schreibst auch noch das ganze Mapping von deinem Service Contract und Data Contracts selbst - vorausgesetzt du hast überhaupt eines. Da du auch hoffentlich nicht nach dem Prinzip Fire & Forget arbeitest, möchtest du bestimmt auch detaillierte Rückmeldungen über mögliche Fehler auf der Gegenseite haben. Ausserdem möchtest du vielleicht synchrone Aufrufe tätigen können und nicht auf eine (eventuelle) Antwort per WM_COPYDATA warten. Wenn Morgen das Requirement reinflattert, dass du das ganze auch noch bitte über pipes und tcp zugänglich machen sollst, wirst du erst mal ein paar Tage oder Wochen beschäftigt sein. Mit den richtigen Entscheidungen hast du das alles in 5 Minuten gemacht, denn das Rad muss man nicht mehr neu erfinden.

Isn die Methode die oben so steht in Ordnung, oder gibts da größere Fehler?

Lg

Hat sich alles geklärt,danke.
Mit dem Synchronisieren habe ich es letzendlich nicht hinbekommen, ist mir noch zu schwer, hatte bis jetzt noch kaum Kontakt mit der Win API.
Habe es jetzt anders geregelt, ich lese die Sekunden aus und habe jedem Fenster eine feste Anzahl von Sekunden zugeordnet.
Damit klappt es denke noch effizienter und besser als mit irgendeinem Synchronisieren.
Danke trotzdem.

Lg

Henry

@Luckie: Du klingst ja fast so, als wäre ein kleiner Semaphor oder Mutex zu viel Aufwand!

@HenryHux: Spätestens, wenn Dir dein Programm auf einem System mal gewaltig um die Ohren fliegt, weil Windows2 Programmen gleichzeitig den Zugriff auf die Daten gibt, die da unsynchronisiert rumflattern, weißt Du, dass Du das hättest vermeiden können.

Und SOOOOO schwer ist das auch nicht:

Programminitialisierung:
Alle Programme legen (den gleichen!!!) Semaphor/Mutex an (holen sich da ein Handle, bei Mutexen handhabt Windows das etwas anders als POSIX, ACHTUNG!)

Lesen von Daten:
- Programm X sperrt den Semaphor/Mutex
- Programm X schaut, ob's Änderungen gab
- Programm X KOPIERT sich seinen Status
- Programm X gibt den Semaphor/Mutex wieder frei
- Programm X verarbeitet das Änderungsereignis (falls vorhanden)

Schreiben von Daten:
- Programm X sperrt den Semaphor/Mutex
- Programm X schreibt die neuen Daten
- Programm X gibt den Semaphor/Mutex wieder frei
- Programm X Signalisiert anderen Prozessen Änderungen (oder andere Programme pollen)

In Code sind das bei richtiger Implementierung kaum mehr als 20 Zeilen je Routine. Spart einem RICHTIG viel Arbeit beim Debugging!

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.