Hallo,
wie ist es denn Sitte beim Eventhandling seine Bedienelemente im Blockdiagramm zu positionieren?
Außerhalb von den jeweiligen Eventcases die von dem Bedienelement ausgelöst werden oder innerhalb?
Ich würde sie außerhalb hinsetzen, damit andere Eventcases auch deren Werte abfragen können ohne Variablen zu verwenden. Außerdem findet man dann alle Bedienelemente auf einen Blick und muss sie nicht erst in den einzelnen Events suchen.
Ist das ok? Oder gibt es irgendwelche Nachteile bzw. funktioniert das Eventhandling nicht mehr richtig, wenn die Bedienelemente nicht innerhalb des Eventcases sind?
Danke
Ich sag mal, jeder hat da seine eigene Philosophie.
Ich bin in der Regel für "Terminal kommt in den Eventcase, in dem ein ValueChange verarbeitet wird". Ich halte das aber nicht immer 100pro durch.
Auf jeden Fall mache ich dies aber bei Latch-Buttons. Denn ein Latch-Button wird im FP erst wieder auf seinen Original-Zustand gesetzt, wenn das Terminal im BD ausgelesen wird. Wenn du so einen Latch-Button neben der Eventstruktur hast, dann wird der Button erst beim nächsten Durchlauf der Event-Loop zurückgesetzt. Ich persönlich finde diese Verhalten verwirrend.
Gruß, Jens
Ist das nicht in einem normalen Loop auch so? Ich drück den Button und bei der nächsten Loop wiederholung wird er zurückgesetzt? Aso, aber bei den Events kann es natürlich etwas dauern bis das nächste Event stattfindet. Hm stimmt, andernfalls bleibt er dann gedrückt solang bis wieder ein Event stattfindet. Des is ja doof
Wenn der Eventbutton in dem Eventloop ist, dann wird er gedrückt, er springt in den Case, dort wird er dann ausgelesen und dabei zurückgesetzt. Gut.
Danke Jens.
' schrieb:Ist das nicht in einem normalen Loop auch so? Ich drück den Button und bei der nächsten Loop wiederholung wird er zurückgesetzt? Aso, aber bei den Events kann es natürlich etwas dauern bis das nächste Event stattfindet. Hm stimmt, andernfalls bleibt er dann gedrückt solang bis wieder ein Event stattfindet. Des is ja doof
Falsch, und hier verstehe ich Jens nicht wie er das gemeint hat:
Richtig: Das Rücksetzen findet dann erst beim nächten Schleifendurchlauf statt.
Falsch: Das Rücksetzen findet erst beim nächsten Event statt.
Denn es ist doch so: Beim nächsten Schleifendurchlauf wird wieder auf das nächste Event gewartet. Richtig - das kann dauern. In der Zwischenzeit versucht LV alles andere in der Schleife zu erledigen, was sonst noch an Code anliegt - also unter anderem wird es den Knpof lesen und rücksetzen. Es ist also ziemlich egal, wo man den Latch-Knopf in der Schleife mit der Ereignisstruktur positioniert - ob direkt im Ereigniscase oder nur in der Schleife. Wichtig ist nur, ihn nicht außerhalb der Schleife zu positionieren, in dem sich die Ereignisstruktur befindet.
Wenn es sich nicht um Boolsche Elemente mit Latch-Verhalten handelt, denn ist es durchaus normal, diese Elemente (wegen der guten Übersicht) noch außerhab der äußersten Programmschleife zu positionieren. Ich mache das auch so, und tue das Element nur dann an eine andere Stelle, wenn ich damit eine lokale Variable vermeiden kann.
Hm. Stimmt. Dann hat Jens mit Sicherheit gemeint, dass der Button solang gedrückt bleibt, wie die Operationen im Eventcase brauchen um fertig abgearbeitet zu werden. Und wenn das eine längere Angelegenheit ist, dann kann des schon etwas komisch ausschauen, wenn der Button die ganze Zeit reingedrückt bleibt.
Zitat:Ich mache das auch so, und tue das Element nur dann an eine andere Stelle, wenn ich damit eine lokale Variable vermeiden kann.
Kann man lokale Variablen nicht genau dann vermeiden, wenn man eben die Elemente ganz außen hat (weil dann kann man ja einfach ausgehend von da in die Programmtiefe hinein einen "Draht" legen...) . Oder meinst du in deinem Fall nur zur Übersicht, dass nicht soviele ewig lange Dräht irgendwo rumliegen?
' schrieb:Kann man lokale Variablen nicht genau dann vermeiden, wenn man eben die Elemente ganz außen hat (weil dann kann man ja einfach ausgehend von da in die Programmtiefe hinein einen "Draht" legen...) .
Oh nein, das geht überhaupt nicht. Wenn sie ganz außen liegen, dann werden sie nur ein einziges Mal gelesen - endweder bei Start, oder (wenn freischwebend ohne Draht) sogar bei Stop des Programms. Dieser einmal gelesene Wert würde dann auch auf den angeschlossenen Draht übertragen, der Wert dort würde sich nie ändern, da kannst Du das Element bedienen so oft Du willst.
' schrieb:Hm. Stimmt. Dann hat Jens mit Sicherheit gemeint, dass der Button solang gedrückt bleibt, wie die Operationen im Eventcase brauchen um fertig abgearbeitet zu werden. Und wenn das eine längere Angelegenheit ist, dann kann des schon etwas komisch ausschauen, wenn der Button die ganze Zeit reingedrückt bleibt.
Genau das ist gemeint, Abarbeitung im Event dauert meinetwegen 200 ms, das sieht man als User. Reine Geschmackssache.
Gruß, Jens
Sicher ist das Geschmackssache, aber es spricht auch einiges dafür es anders zu machen. Wenn der Eventcase einige Zeit zur Abarbeitung braucht und der Auslöseknopf springt erst danach heraus, dann ist das nicht etwa blöd, sondern das ist ein sehr hilfreicher Hinweis an den User, daß die Abarbeitung noch läuft und er sich für das nächste Drücken noch etwas gedulden möge...
' schrieb:Sicher ist das Geschmackssache, aber es spricht auch einiges dafür es anders zu machen. Wenn der Eventcase einige Zeit zur Abarbeitung braucht und der Auslöseknopf springt erst danach heraus, dann ist das nicht etwa blöd, sondern das ist ein sehr hilfreicher Hinweis an den User, daß die Abarbeitung noch läuft und er sich für das nächste Drücken noch etwas gedulden möge...
Aber: Ein Event, das "länger" dauert, ist sowieso nicht die feine englische Art..."Langer" Code hat nüscht in nem Eventcase verloren! Basta!
' schrieb:Aber: Ein Event, das "länger" dauert, ist sowieso nicht die feine englische Art..."Langer" Code hat nüscht in nem Eventcase verloren! Basta!
Genau so, und von daher gesehen war es falsch, daß ich diesen hingehaltenen Faden "..was ist, wenn es länger dauert.." überhaupt aufgenommen und weitergesponnen habe...