Verhalten von Ereignisstrukturen

Hi,
Die Beschreibung von 10 Bildschirmseiten lässt sich bei mir auch die Fußnägel hochrollen, aber um Deine Frage zu beantworten:

Es gibt eine Ereignis-Queue, wenn ich also für fünf Buttons Ereignisse definiere und davon drei drücke, werden die auch nacheinander abgearbeitet. Auf diese Ereignis-Queue kann man meines Wissens nach und auch nach Auskunft eines NI-Trainers NICHT zugreifen, sprich, wenn ich gedrückt habe, läuft das ganze auch entsprechend durch. Abhilfe kann man mit der Kombination "Frontpanel-Aktivitäten während Event-Ausführung deaktivieren" (Haken im Event-Konfigurationsmenü recht weit unten, meine ich) und entsprechenden Aktivierungen und Deaktivierungen der Knöpfe im Event-Case realisieren.

Zu den Tipps und Erfahrungen nur folgendes:
- Den Anschluss des Bedienelements möglcihst in den Event-Case reinpacken, wo das auch bearbeitet wird - das macht das ganze ein bisschen zuverlässiger, wenn man mit Click-Events arbeitet. Parallele, nicht deterministische Programmabarbeitung in LV und so...
- Ich persönlich bin großer Fan von State-Machines mit einem Event-Case, der die entsprechende Programfunktion steuert und halt für jede Funktion einen eigenen State hat. Könnte Deine 10 Bildschirmseiten auflösen und dann kann man sich auch tatsächlich das Wait in der While-Schleife sparen. Falls die einzelnen Programmteile an sich recht simpel sind (also nur von einer Konfiguration abhängen) und man diese ggf. auch mehrfach nutzen möchte, sind Queued State Machines eine coole Sache, weil man dann einfach mehrere Dinge nacheinander programmieren kann und m.E. die Fehlerbehandlung einfacher zu machen ist, weil man an jeder STelle an jede Stelle des Programms springen kann, ohne sich die vorherigen Zustände merken zu müssen. Geht in der State Machine nur kompliziert...

Grüße und viel Spaß,

ch