Hi,
sorry, vielleicht übersehe ich irgendwas, aber ist doch die gleiche Frage wie im "alten" Thread? Da gab es aber schon einige (
imho) gute Hinweise, wie du es angehen kannst/solltest.
Ehrlich gesagt finde ich es etwas unhöflich, dass du hier nur auf die dortigen Beiträge verweist, eine kurze Zusammenfassung was genau das Problem (hier aktuell in dem Thread) ist, ist doch um einiges netter. So müssen sich Leute die dir helfen wollen erst die Mühe machen dort alle Beiträge zu lesen und erfahren nur so, um was für eine Kommunikation es sich überhaupt handelt. Was noch völlig unklar ist (oder ich habe es übersehen), wann / wodurch wird das Flag gesetzt?
Ich gehe mal davon aus, dass es immer noch um die Kommunikation per RS232 geht. Da stellt sich dann schon die Frage, was für eine Komponente verwendest du zur Kommunikation?
Ich empfehle dir an dieser Stelle einfach mal die TComport (gibt's bei Sourceforge) Komponente, diese bietet dir recht komfortabel alles was du (wahrscheinlich) benötigst und kann ein Ereignis auslösen, wenn etwas empfangen wird. Genau dieses Ereignis sollte bei dir ja zum Auslösen bzw. setzen des Flags führen.
An sich hast du auch schon eine gute Methode gefunden, das
DP Delay (sollte sich unter dem Namen oder ähnlich in der Codelib finden lassen). Der Ansatz beruht auf der WaitForMultipleObjects-Funktion. Diese solltest du dir einfach mal näher anschauen. Sie legt einen Prozess schlafen, bis ein bestimmtes Ereignis signalisiert wird. Dabei gibt es hier die Möglichkeit, dass verschiedene Ereignisse das "Aufwachen" ausgelöst haben können. Einerseits natürlich ein Timeout, andererseits Fensternachrichten (verschieben, schließen,...) und zu guter Letzt kannst du auch ein Array von
Handle auf Signale übergeben. Da das Delay wirklich immer eine feste Zeit warten soll, wird hier natürlich absichtlich auf das Timeout gewartet. Das ist aber nur ein spezieller Fall, wie man die Methode verwenden kann. Schau dir einfach mal dazu die Hilfe an. Da findest du dann, dass (und wie) die Funktion zurückgibt, welches Signal ausgelöst wurde. Du musst also im Prinzip nicht mehr machen, als ein eigenes (globales) Signal verwenden, dass du immer zurücksetzt, bevor du einen Befehl verschickst und mit dem Eintreffen der Daten über RS232 (wie gesagt eigenes Event bei der TComPort-Komponente) setzt du dieses Signal. In der Methode, in der du den Befehl sendest wartest du dann mittels MsgWaitForMultipleObjects und muss nur noch unterscheiden, ob ein Timeout, dein Signal oder etwas anderes zum Verlassen der Methode führt und entsprechend handeln.
Wie du die Befehle serialisiert absetzt ist dann sicherlich trivial.
[ADD nach roten Kästen]
Das Senden und Empfangen würde ich an deiner Stelle wirklich eher in eine Methode packen, da hier eine Beziehung zwischen gesendetem Befehl und empfangener Antwort besteht. Um hier mal auf der Idee von Muetze1 aufzubauen, du kannst so leicht mit einem Sperrobjekt (z.B. ein
Mutex) das erste Element der Liste entfernen und lokal speichern. Damit könntest dann theoretisch auch parallel die Liste abarbeiten, wenn du mehr als eine (gleichartige) Schnittstelle bedienst. Ist für Ladegeräte wohl eher nicht nötig, aber es kann ja mal andere Aufgabenfelder mit gleicher Idee geben
[/ADD
Gruß Der Unwissende