Community video nugget: Locked FP's with Event structures

[TCPlomp]

A common problem with event structures is a locked 'Front Panel'. I made a small video on this subject.

It discusses the following situations:

• Unwanted events during the duration of another event
• Locking a front panel when a certain event occurs
• Unwanted locking of the Front panel due to a non-active event structure (dual event structures specifically)

A previous nugget on an advanced level is found here Dynamic event registration

A list of previous nuggets is found here.

Ton

[tst]

You made an editing choice there which really confused me at first. In the last VI, after you pressed the process button, changing the color should have actually caused the VI to finish execution, because the second event structure executes after the first and the locking is only done until all the code in the case executes. I had to do back to see that the code is locked because you actually cut the video, so that when you change the color, the button was actually NOT pressed before and the first event structure did not yet execute.

[F._Schubert]

Nicely done, important topic, but I fear that we don't get the practical impact on this.

So, I want to provide an example I ran into that situation (I was helping an unexperienced wireworker to debug his app).

<Seastory>

The app was a state machine, where each major state corresponds to a tab of an invisible tab control (this idea was introduced to me by the blume book). So each of these states had an event structure handling only the controls of the tab currently visible. During developement time, the tab was still visible, so we did navigate through the tab during demo/code review and it just happend to click a button in the wrong tab -> everything was locked.

</Seastory>

I am still unsure about the implications, here my possible 'solutions':

* Do not use that kind of design (my current opinion, but I still need a better way if I need a wizard-like app/routine)

* Modify this design to catch this problems, maybe as 'Event-Driven-Queued-State-Machine' (search expressionflow for the implementation), so STate machine and event structure are independent

* Blame LV for making the Event structure 'too easy', so ask for register event (we actually can do this) and for methods to work on the event queue (event registration refnum) like flush/lock/unlock/timeout

Felix.

[Norbert_B]

Nice nugget showing one pitfall people fall into when starting with event based programming in LV or not thinking about proper architecture of the application.

---

F. Schubert wrote:
[...]

* Do not use that kind of design (my current opinion, but I still need a better way if I need a wizard-like app/routine)[...]

---

Using several event structures handling events from the same source is imho the thing every developer should avoid. In this case, the UI is to be considered to be a single source, regardless of any tabcontrols or similar.

There are situation where having different event structures handling different UI elements works very good, but if adding new functionality, you always have the risk of introducing this kind of dead lock.

Therefore, thumbs up for bringing this issue up in this webcast!

Norbert