Schalterverhalten während Timeout bei Eventstruktur

' schrieb:Das Problem liegt nur dadrin, dass ich sonst nicht weiter weiß. Und ich verwende die Eventstruktur nicht parallel.
Ich verwende lediglich zwei identische Eventstrukturen ineinander. Persönlich weiß ich jetz nicht, wie das Programm
damit ein Problem haben könnte...

Ich kann Dir auch nicht konkret sagen, warum man nicht zwei Timeout-Schleifen verwenden sollte. Zum direkten Blockieren des Programms führt es dann, wenn in mindestens einer der beiden Schleifen das Timeout unendlich (-1) gesetzt ist.
Man kann es - soweit ich das sehe - mit einer State-Machine-Struktur immer so einrichten, daß man mit einer zentralen Event-Verwaltung auskommt. Und diese Lösung würde ich bevorzugen.

Anzeige

In diesem Fall nicht...
Ich muss genau zu dem Zeitpunkt, an dem die Schalter aktualisiert werden, nachsehen,
ob das Event ausgelöst hat. Evtl. kann man es mit einem Methoden- oder Eigenschaftsknoten lösen,
hab aber dazu nicht gefunden. Brauch auf jedenfall im Timeout der äußeren Eventstruktur eine Eventabfrage.
Danke für die vielen Antworten.

' schrieb:Ich muss genau zu dem Zeitpunkt, an dem die Schalter aktualisiert werden, nachsehen,
ob das Event ausgelöst hat. Evtl. kann man es mit einem Methoden- oder Eigenschaftsknoten lösen,
hab aber dazu nicht gefunden.

Ich sehe ja in den Fragmenten nicht durch, aber da könnte man doch z.B. auch Flags verwenden: Wenn das Ereignis stattfindet, wird das Flag (mit lokaler Variablen) gesetzt. Später wird es (das vorborgene boolsche Bedienelement) abgefragt und die darauf basierende richtige Entscheidung getroffen. Mit einer anderen lokalen Variablen wird es dann rückgesetzt.

Falls die Lösung noch von Interesse ist.

Man wandelt das Bedienelement (der Schalter) in ein Anzeigeelement um.
Dann erstellt man 3 Ereignissknoten des Anzeigeelements(Wert).

Im Timeout kannst dann den Wert je nach Bitwert auf True oder False setzen, und im Event für den Klick auf das Anzeigelement liest du erst den Wert mit einem Eigenschaftsknoten aus, Wert negieren und wieder mit einem Eigenschaftsknoten reinschreiben.

ich probiers gleich mal aus.

edit: funktioniert

Schon klar Lucki aber ich muss irgendwo erfahren ob das Event gesetzt wurde und demnach das Flag
setzten. Am Anfang der Eventstruktur bringt es mir nichts und am Ende auch nicht. Der Knackpunkt ist der, wenn der
User den Button drückt, wenn das Programm gerade im Timeout ist aber noch bevor die Bedienelemente aktualisiert sind.
Dort muss ich die Events erfahren.

' schrieb:Schon klar Lucki aber ich muss irgendwo erfahren ob das Event gesetzt wurde und demnach das Flag
setzten. Am Anfang der Eventstruktur bringt es mir nichts und am Ende auch nicht. Der Knackpunkt ist der, wenn der
User den Button drückt, wenn das Programm gerade im Timeout ist aber noch bevor die Bedienelemente aktualisiert sind.
Dort muss ich die Events erfahren.

Du müstest eben mal ein ganz stark reduziertes VI mit nichts anderem als was zum Problem gehört posten. Dann könnte man etwas dazu sagen.
Timeouts gibt es solche und solche: Hat der Ereignisrahmen einen Timout, dann liegt der Rahmen während der Wartezeit auf der Lauer nach Ereignissen. Es wird sofort behandelt. Bei einer Wartefunktion irgendwo anders ist der Ereignisrahmen in dieser Zeit überhaupt nicht aktiv und ein Ereignis wird erst behandelt, wenn die Rahmen wieder an der Reihe ist. Sollte also möglichst vermieden werden.
Ereignisstrukturen sind ein "nice to have", kein "must have". Dh. alles was sich programmieren läßt geht auch ohne sie - so wie in älteren Versionen von LV. Deshalb ist doch klar, und zwar ohne überhaupt hinzuhören wie Du argumentierst, daß sich das Problem auch ohne Ereignisstrukturen lösen läßt - oder eben auch mit nur einer.

Ich sehe es anders.
Es geht entweder ohne oder mit zwei ^^.
Modran, deine Lösung funktioniert nicht, da ich nicht nur Schalter, sondern auch Auwahlboxen habe
und deshalb nicht einfach den vorherigen Wert negieren kann.