RE: Einfrieren der GUI bei Eventcase
Die Eventcases sind eine gute Möglichkeit um Eingaben vom Benutzer abzufangen und zu verarbeiten. Wie Gerd jedoch richtigerweise erwähnte, darf das dein Programm idealerweise nicht blockieren, indem die Abarbeitung eines einzelnen Eventcases zuviel Zeit in Anspruch nimmt.
Die Verwendung von Queues an der Stelle hat durchaus praktische Vorteile. Einfaches Beispiel:
Du erzeugst zwei While Schleifen. Deine obere beinhaltet deine Eventstruktur und jeder Case wiederrum ein Enqueue Element in Kombination mit einem Enum (unbedingt TypeDef!) oder String.
Deine untere While Schleife beinhaltet dann eine Case Struktur. Jeder Case entspricht einem Enum bzw String Eintrag, wie du sie in der oberen Schleifen verwendet hast. Dazu packst du noch einen Case, wenn der Fall Eintritt, dass die Queue leer gelaufen ist (Timeout): Idle
Du prüfst "unten" nun deine Queue auf neue Einträge und gibst sie an deine Casestruktur weiter. Sind keine Vorhanden, wartest du einfach auf neue.
Nun hast du ein Konstrukt, mit dem du beliebig Kommandos aus der Eventstruktur weiterverarbeiten kannst, ohne diese zu blockieren.
Das heißt natürlich nicht, dass das Event auch zwingend bearbeitet wird. Blockiert deine untere Schleife nun, weil ein VI noch läuft, dann wird das Folgeevent nur ausgeführt, wenn das entsprechende VI mit seiner Arbeit fertig ist. Dir steht es natürlich frei, Queues, Notifier und Co. an entsprechende VIs zu übergeben. So lassen sich dann auch Benutzereingaben aus der zuvor erwähnten Eventstruktur in einem laufenden VI behandeln (z.B. die Verwendung eines Stopknopfes in Verbindung mit einem Notifier).
Gerade wenn man mit den Sachen nicht vertraut ist, hilft es enorm, einfach mal wild auf einem leeren Blockdiagramm diverse Dinge auszuprobieren. Was soll schon kaputt gehen? Wenn es dann immer noch hakt, bekommst du hier kompetente Hilfe im Forum.
|