Hallo catbull,
nachdem du ja über das Wochenende schon einiges zu Thema "THINK DATAFLOW!" gelernt hast (Link in meiner Signatur!), noch ein paar Hinweise/Gedanken:
Zitat:Gibts Gründe dafür hier eher einen Case zu verwenden oder tuts dieses if-Dreieck genauso?
- FGVs, die einfach nur Werte speichern/lesen lassen (wie in deinem Bild), bringen keinen echten Mehrwert ggü. einer einfachen globalen Variablen! Du handlest dir nur zusätzlichen Overhead ein! RaceConditions (Link in meiner Signatur!) kannst du mit einer solchen einfachen FGV auch nicht vermeiden: du weißt weiterhin nicht, wer zuerst lesen oder schreiben darf…
- Erst, wenn man weitere Methoden implementiert (z.B. Daten speichern oder aus Datei lesen), wird es wirklich sinnvoll! Und ein ErrorIO ist dann auch Pflicht…
Zitat:Ich versuche globale Variablen zu vermeiden,
Gegen globale Variablen ist nichts einzuwenden, wenn man sie
bewußt verwendet.
Warum sollte es verkehrt sein, zu Programmstart in einer globalen Variablen die aktuelle Programmversion (und ähnliche Informationen) zu speichern, wenn man hinterher nur noch lesend darauf zugreift? (Stichwort "WORM"= "write once read multiple", zu finden im NI-Forum).
Es gilt wie sonst auch: der Programmierer sollte wissen (und dokumentieren), was er da macht…
Zum Thema "Variablen":
Dieser Begriff wird in LabVIEW
anders verwendet als in textbasierten Sprachen.
- Dort benutzt du ihn, um Daten von einem Codeteil zum nächsten zu bringen: in LabVIEW benutzt man dafür den Draht!
- Dort benutzt du ihn, um Daten zu (in einem Memorybuffer) speichern: auch hier benutzt LabVIEW den Draht - oder ein Schieberegister/Feedbacknode!
Hier mal ein Beispiel für ein Snake-Spiel:
- Es gibt genau 4 FP-Elemente, die alle für den User sichtbar sind: String (Hinweistext), Spielfeld, Punktestand, Lebens-Anzeige der Schlange.
- Alle Daten befinden sich in Drähten und im Schieberegister.
- Es werden keine "Variablen" benötigt!
- Tetris sind fast identisch aus (dort habe ich nur einen QMH eingebaut)…
