Guten Abend, ich versuche mich gerade an meiner ersten GUI in C# für Windows. Es läuft eigentlich recht gut. Bis auf eines das mir nicht richtig klar ist. Wenn ich Code schreiben will der ständig läuft zB so wie in C auf einem Mikrocontroller die main wie mache ich das? Oder ist das gar nicht erlaubt? Lg
Auslagern in einen Thread, sonst blockierst du die GUI. Im Thread dann ein while(true) und fertig.
mein erstes PC Program schrieb: > Wenn ich Code schreiben will der ständig läuft zB so wie in C auf einem > Mikrocontroller die main wie mache ich das? Für was glaubst du das zu brauchen? Ich wüsste keine sinnvolle Aufgabe für so etwas. Eingaben durch den Benutzer erzeugen Events, I/O (wie Datei- oder Netzwerkzugriffe) kann man asynchron abwickeln usw. Es besteht eigentlich gar kein Grund dafür, Code zu haben, der permanent unnötig Rechenzeit verbraucht.
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.
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
Dirk schrieb: > Wozu den Thread mit einer Endlosschleife 100% Last geben? Normalerweise > nutzt man Events dafür. Und selbst wenn man unbedingt diese Endlosschleife bräuchte (wobei ich keinen sinnvollen Grund dafür wüsste), würde ich als erste Anweisung "Thread.Sleep(1);" reinschreiben. Dadurch kann der Scheduler vom OS wenigstens noch etwas sinnvolles mit der Zeit anstellen. Das entlastet die CPU dann schon sehr - und ein Durchgang alle x Millisekunden reicht sicherlich auch noch...
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. Was ist "winzig klein"? 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. > Wie macht man es dann? Wenn man schon eine objektorientierte Sprache benutzt, definiert man sich eine State-Klasse und leitet für jeden konkreten State eine Klasse davon ab. Das ist etwas mehr Schreibaufwand, aber dafür ist es leichter erweiterbar, und die Statemachine muss nicht an einer Stelle sämtliche Zustände und Übergänge auf einem Haufen haben. Sie muss nicht mal wissen, welche es überhaupt gibt. > 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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.