Modularer Aufbau

' schrieb:Das macht man deswegen, weil der Code in nem Eventcase evtl. länger dauern kann...und erst wenn dieser Code beendet ist, reagiert die Eventstruktur auf das nächste Event!

Darum ist das Vorgehen beispielhaft so:

- Schleifeniteration n: Event "Messen" auslösen
- Schleifeniteration n+1: Im entsprechenden Eventcase die "Anfrage weiterleiten" an Case "Messen"
- Schleifeniteration n+2: Case "Messen" wird erreicht, Messung durchführen (z.B. 1000 Messwerte abholen), dann Entscheidung ob weiter "Messen" oder z.b. "Auswerten" oder "Beenden"
- Schleifeniteration n+3: Entweder wieder Case "Messen" anspringen (nächste 1000 Werte) oder "Auswerten" oder "Beenden"
- Schleifeniteration n+4: ...

Gruss
Achim

Hallo Achim,

Dein initieller Grund warum man sowas macht ist aber nur effektiv, wenn man die State Machine mit Queues macht und die Event-Abhandlung in eine andere parallele Loop setzt als die eigentliche Event-Detektion.

Persönlich mache ich das aber eher selten. Was ich normalerweise habe ist eine Case Struktur die die verschiedenen States abarbeitet und im Default case davon die Event-Struktur. Der Hauptgrund warum ich die Abarbeitung bestimmter Events überhaupt in einen State setze ist vor allem der dass solche States oft von verschiedenen Events getriggert werden können. Zum Beispiel hast Du Menus die bestimmte Aktionen triggern oder auch Kontrollelemente. Auf diese Weise wird der eigentliche Code nur einmal implementiert. Auch ist es bei komplexeren Userinterfaces oft so dass die verschiedenen Aktionen recht komplex werden können, und dann teile ich oft eine Aktion in mehrere Unterstates und mache ich aus dem State Register ein Array von States wo neue Aufgaben am Ende angehängt werden können und der nächste (Sub)State jeweils am Anfang weggeholt wird.

Dies ist extrem flexibel da man eine bestimmte Aktion in mehrere Sub(States) aufteilen kann und diese dann aus verschiedenen Teilen des Programmes in unterschiedlicher Reihenfolge aufrufen kann. Auch kann man durch Hinzufügen eines neuen States am Anfang eine bestimmte Aktion priorisiert ausführen lassen indem man sie quasi in die Statequeue hineinschiebt.

Aber hier gleich eine Warnung: Eine solche Architektur ist ohne ein sinnvolles Statechart praktisch nicht mehr zu kontrollieren, es sei denn man besitzt über ein Gehirn das in dreidimensionaler Sequenzlogik ausgezeichnet trainiert ist.

Rolf Kalbermatter