C# Hauptschleife?

Auslagern in einen Thread, sonst blockierst du die GUI. Im Thread dann 
ein while(true) und fertig.

Nutze einen Timer in einem Thread der nicht der GUI-Thread ist.

Donni D. schrieb:
> Auslagern in einen Thread, sonst blockierst du die GUI. Im Thread dann
> ein while(true) und fertig.

Ok was heißt das genau?

Lars R. schrieb:
> Für was glaubst du das zu brauchen?

Ich möchte eine State Maschin bauen.
Wenn ich zB  auf irgendwas warte möchte ich in diesem Case bleiben.

mein erstes PC Program schrieb:
> Ich möchte eine State Maschin bauen.
> Wenn ich zB  auf irgendwas warte möchte ich in diesem Case bleiben.

und warum? Zum ändern vom State wird doch wohl ein Event kommen oder 
nicht?

Wie schon oben geschrieben, kann man das mit eine Thread oder 
Backgroundworker machen. Beim arbeiten mit der Seriellen-Schnittstelle 
mache ich das auch so, aber bei einer einfach GUI-Anwendung braucht man 
so etwas wirklich nicht.

Für Einsteiger wäre BackgroundWorker "state of the art".

Wozu den Thread mit einer Endlosschleife 100% Last geben? Normalerweise 
nutzt man Events dafür.

Hi,

für eine state machine brauchst Du eigentlich keinen "dauernd" laufenden 
Code. Vielmehr fragt sich, durch was die state machine den Zustand 
ändert. Zeit? -> Timer; Mausklick? -> entsprechende (oben schon 
erwähnte) Eventroutine; etc.
Den Zustand von ein paar Variablen darfst Du in solch einer Eventroutine 
verändern. Eine langwierige Berechnung/Ports am PC ansteuern solltest Du 
in den schon erwähnten Thread/Backgroundworker auslagern. C# hat dafür 
sowie für gängige Problemchen wie die Synchronisierung (aus einem Thread 
die GUI ansteuern ist auch wieder nicht erlaubt) recht elegante 
Lösungsmöglichkeiten.

Die state machine selbst kannst Du durch Variablen abbilden, oder aber 
(sehr viel eleganter) durch Klassen. Für den Einstieg würde ich hier 
aber den einfachsten Weg gehen. Das, was Du vom µC am ehesten kennst, 
sind "public static" definierte Klassenvariablen. Die eleganteren 
Möglichkeiten kannst Du dann später lernen.

Gruß, jois3

mein erstes PC Program schrieb:

> Ich möchte eine State Maschin bauen.

Schön.

> Wenn ich zB  auf irgendwas warte

Ein endlicher Automat "wartet" nicht. Er ist in einem
Zustand, der durch die Zustandsvariable(n) bestimmt
wird.

Wenn ein passendes Eingangssignal kommt, erfolgt ein
Zustandsübergang, d.h. die Zustandsvariable ändert
sich. Das war's.

Ach so, ja: Passendes Ausgangssignal muss manchmal
auch noch erzeugt werden.

> möchte ich in diesem Case bleiben.

So lange sich die Zustandsvariable nicht ändert, bleibt
der endliche Automat natürlich im selben Zustand. Das
ist laut Definition der Zustandsvariablen so.

Nebenbei: switch/case für einen endlichen Automaten ist
meiner Meinung nach das Tor zu Hölle -- zumindest für
Automaten, die nicht winzig klein sind.

Possetitjel schrieb:
> Nebenbei: switch/case für einen endlichen Automaten ist
> meiner Meinung nach das Tor zu Hölle -- zumindest für
> Automaten, die nicht winzig klein sind.

Wie macht man es dann?
Gibt es ein "kleines" gutes Beispiel?
LG

mein erstes PC Program schrieb:

> Possetitjel schrieb:
>> Nebenbei: switch/case für einen endlichen Automaten ist
>> meiner Meinung nach das Tor zu Hölle -- zumindest für
>> Automaten, die nicht winzig klein sind.
>
> Wie macht man es dann?

Wie "man" es macht weiss ich nicht.

Ich kenne zwei Strickmuster: Wenn es viele "irreguläre"
Übergänge und insgesamt relativ wenige Zustände gibt,
kann sich schlicht und ergreifend eine Tabelle für die
Überführungsfunktion lohnen.

Wenn die Anzahl der Übergänge nicht dramatisch viel
größer ist als die Anzahl der Zustände, dann mache ich
es so, wie ich's in der Steuerungsprogrammierung gesehen
haben: Für jeden Zustand eine Regel nach dem Schema

  if { $zustand == "irgendwas" } { ... }

In {...} wird das Eingangssignal abgefragt, der neue
Zustand bestimmt und das richtige Ausgangssignal gesetzt.
Die Zustände werden natürlich in einer Zustandsvariablen
gespeichert; im einfachsten Falle alle Zustände durch-
nummerieren.
Alle Regeln werden einfach nacheinander aufgelistet. Wenn
der Automat Rechenzeit bekommt, klimpert er einfach alle
Regeln nacheinander durch.

Wichtig:
1. Im Geiste immer ganz klar zwischen Überführungsfunktion
   und Ausgabefunktion trennen. Das KANN im Einzelfall mal
   dasselbe sein (MOORE-Automat), aber man muss wissen,
   dass dies eine Ausnahme ist.
2. Ich programmiere immer erst alle "regulären" Zustände
   herunter, dann dichte ich alles gegen Fehler (=nicht
   zulässige Eingangssignale) ab, und zum Schluss mache
   ich mir über die Anfangszustände Gedanken.

Rolf M. schrieb:

> mein erstes PC Program schrieb:
>> Possetitjel schrieb:
>>> Nebenbei: switch/case für einen endlichen Automaten ist
>>> meiner Meinung nach das Tor zu Hölle -- zumindest für
>>> Automaten, die nicht winzig klein sind.
>
> Was ist "winzig klein"?

Höchstens drei Zustände, würde ich sagen.

> Ich finde es bei nicht riesig großen Statemachines schon
> noch machbar, aber man darf natürlich nicht den gesamten
> Code in einen großen switch/case-Klumpen schreiben.

Naja, genau das meinte ich ja.

Vielleicht ist das ein rein imaginärer Unterschied, aber
es gelingt mir NIE, gleich im ersten Anlauf alle Anfangs-
und Fehlerzustände korrekt zu überblicken und zu behandeln.

Ich muss das schön nacheinander machen; jeder Zustand eine
eigene Regel.