mehrere Events schlecht

Ich habe im Lehrbuch gelesen, dass zwei Event-Strukturen parallel "schlecht" sind, sondern alles wenn möglich in eine gepackt werden sollte.

So schön - so gut. Was hab ich getan? Ich habe mir mehrere Menuefolgen definiert und einge davon auch als typdef-Dateien abgespeichert. Darunter habe ich einen Bereich mit Optionsfeldern. LabView hat mir dazu den Rahmen Optionsfelder bereitgestellt und ich habe vier Optionsfelder eingefügt.

Folgendes möchte ich tun

Ich habe drei Schalter, nennen wir sie

Signal erzeugen
Messung starten
Beenden

Diese drei Schalter kann ich mit der Eventstruktur abfangen und weiter reagieren. Beispielsweise soll das Optionsfeld erscheinen, denn ich Einstellungen betätige. Dass geht auch mit dem Eigenschaftsknoten-sichtbar - alles schön.

Jetzt kann ich bei den Events auch Operationsfelder-Wertänderungen erfassen, aber nicht die Wertänderungen im einzelnen. Je nach angeklicktem Wert sollen verschiedene Einstellmöglichkeiten sein.

Bei den Operationsfeldern ist immer nur eins auswählbar:

Sinus
Sägezahn
DC

aber zu jedem Operationsfeld gibt es noch unterschiedliche Einstellmöglichkeiten, die also noch ein drittes Menü erzeugen.

Jetzt könnt ich innerhalb vom Ereignis Optionsfeld-Wertänderung eine case-Struktur einbauen, die die Operationsfelder auswertet und dazu die nächste Menüebene einblendet. Dazu muss ich aber immer die einen Eigenschaftsknoten von den weiteren Untermenüs - z.B. Einstellungen_Sinus auch ein- und ausblenden, dass heisst, ich muss jeden Eigenschaftsknoten von Sinus_einstellungen, DC_einstellungen ... an den case dranhängen und den jeweiligen Wert True/False rausführen. Es gibt zwar auch die Möglichkeit - "Standard verwenden, wenn nicht verbunden", aber so hab ich an dem case für die Auswertung von Optionsfeldern-Werteänderung schon mal drei Schleifentunnel dran und wenn noch weitere Optionsfelder hinzukommen, dann erhöt sich da die Anzahl.

Ist das problematisch, wenn ich mehr und mehr Schleifentunnel daran setzen? Es macht auch keinen Sinn, wenn ich die jeweilge Aktion in das case reinsetze, ich muss ja beim Wechsel z.b. von Sinus auf Sägezahn das eine Fenster ausblenden und das andere einblenden.

gibt es vielleicht noch eien Tipp, wie man mehrfach verschachtelte Menues geeignet erstellen kann?

Hallo Hasenfuss,

Tipp: Verwende doch ein Tab-Element.
Damit schlägst du gleich zwei Fliegen mit einer Klappe: Der User muss sich (wie bei deinem Optionsfeld) für einen Signaltyp entscheiden, hier durch Auswahl eines Tabs. Und da der User sich einen Tab auswählt, bekommt er automatisch die dazu passenden Einstellelemente zu sehen...

Zitat:Ist das problematisch, wenn ich mehr und mehr Schleifentunnel daran setzen?

Zusammengehörende Dinge sollte man in (typdefinierten) Clustern bündeln...

Da du schon die Hilfe/Kommentare zu Eventstrukturen gelesen hast, noch folgendes: Terminals der Bedienelemente, deren (ValueChange-)Event ausgewertet wird, sollten im Eventcase liegen. Damit wird bei Schaltern die Latch-Operation (durch das Lesen der Terminals) ausgeführt!

Ich wollte jetzt keinen neuen Thread erstellen, sondern stell meine Frage einfach nochmal hier mit rein, weil es auch mit Events zu tun hat.

Wenn ich Bedienelemente erstelle, an die nichts anschließe, die aber mit Events verbinde - ist es dann egal, wo die Bedienelemente innerhalb des Blockdiagramms positioniert werden? Sollten die eher in die Haupt-Schleife mit rein, falls man mit einer while-Schleife arbeitetet ? Oder koennen die auch ausserhalb des Fehlercases liegen?

Bei den meisten Bedienelementen ist es egal. Man kann sie außerhalb der aller Schleifen positionieren. Wenn man allerdings den Wert noch irgendwo anders im Programm lesen will, verwende ich lieber dort das Bedienelemet als daß ich eine lokale Veriable erstelle.

Ein wichtige Ausnahme sind boolsche Elenete mit Latch-Verhalten. Die müssen gelesen werden, damit sie von selbst wieder herausspringen. Also müssen sie sich z.B im Eeignsicase befinden.
Hierzu noch zwei Tips:
1. Manchmal wird überflüssigerweise in den Ereigniscase ein false/true case zur Knopfbehandlung platziert. Das ist redundant, denn der Bediener setzt immer nur auf true. Das Rücksetzen erfolgt programmgesteurert und löst kein Ereignis aus.
2, Beim Latch-Verhalten hat man die Wahl zwischen "Latch beim Drücken" und "Latch beim Loslassen". Beides ist möglich, allerdings fehlt bei "Latch beim Drücken" meist das "Bedienerlebnis": Der Knopf springt so schnell wieder heraus, das man nicht wahrnimmt, dass er überhaupt gedrückt wurde. Deshalb ist "Latch beim Loslassen" im allgemeinen die besere Variante.

Ich habe noch eine Frage - vielleicht eine blöde Frage - aber ich hab die Antwort noch nicht gefunden:

Ich definiere ein Ereigniscase mit mehreren Ereignissen. Wird ein case ausgelöst - wird dann das Ereignis erst abgearbeitet und so lange werden keine anderen cases bearbeitet? Oder gibt es einen Speicher - ähnlich einer Queue, wo die Ereignisse hintereinander gepuffert werden und dann der Reihe nach wie sie hereinkommen abgearbeitet werden?

Ich denke daran an die uC-Programmierung und den Interrupts - so stelle ich mir von der Funktion einen Ereignis-Case vor. Dabei gilt bei der Mikrocontrollerprogrammierung, dass man die Aufgaben in den Interrupts so kurz und knapp wie möglich halten soll, damit keine Ereignisse verloren gehen - z.B. wenn man Daten einliest und parallel noch eine Speicheroperation mit den Interrupts in Gang setzt. Natürlich könnte man hier nun argumentieren, die Rechner, wo LabView heute drauf läuft, sind um eine 1000er Potenz schneller als ein Mikrokontroller mit vielleicht 10-20 MHz Taktfrequenz, dabei könnte man das vielleicht bei LabView vernachlässigen, aber ich frag einfach dennoch mal Euch Spezialisten hier in dem Forum und freue mich auf Eure Antwort.

---

(21.12.2012 13:47 )Lucki schrieb:  ...

Ein wichtige Ausnahme sind boolsche Elenete mit Latch-Verhalten. Die müssen gelesen werden, damit sie von selbst wieder herausspringen. Also müssen sie sich z.B im Eeignsicase befinden.
Hierzu noch zwei Tips:
...

Meine Frage dazu - gelesen werden bedeutet, dass ich das Element mit einer Datenleitung verbinden muss, damit ein Schalter mit Latch-Verhalten "gelesen" wird? Müsste ich dann z.b. den Schalter ProgrammStopp zum Beenden der while-Schleife in den Ereignis-case reinsetzen und dann nicht eine TRUE-Konstante nach aussen (in den Tunnel) schicken, sondern dierekt den Schalter mit dem Datentunnel verbinden? Oder reicht es einfach nur aus - wie dort beschrieben, den in den Ereignis-case einzufügen, damit er "gelesen" wird ohne eine Datenanbindung?

Das Letzgenannte ist richtig: Der Knopf muss nicht wirklich gelesen werden, man braucht kein Datenanbindung durch einen Draht. Es reicht aus, dass er im Falle eines Drahtes gelesen werden würde.
Aber so etwas ist ja in 5 min jederzeit mit einem einfachen Test feststellbar. Ich verstehe immer nicht, warum Viele lieber umständlich das Forum befragen anstatt schnell mal selbst etwas zu testen.

Zitat:Wird ein case ausgelöst - wird dann das Ereignis erst abgearbeitet und so lange werden keine anderen cases bearbeitet? Oder gibt es einen Speicher

Nicht "Oder", sondern "Und". Ein Ereigniscase wird nicht unterbrochen, solange er abgearbeitet wird, und es gibt eine (fast unbegrenzt große) Queue, in der die noch anstehenden und neu hinzukommenden Ereignisse gespeichert werden. Es geht kein Ereignis verloren.
Ereignisse sind allerdings kein Interrupts. Oder nur insofern, dass beim Eintreten eines Ereignisses das Programm zwar sofort unterbrochen wird, aber nur, um den Eintrag in der Queue zu erstellen.
Wann und inwieweit das dann tatsächlich abgearbeitet wird, hängt davon ab, dass die Ereignisstruktur vom Programm ab und zu tatsächlich angesteuert wird.

Anzeige