Lock front panel in an event structure

[altenbach]

---

@Ravi Beniwal wrote:

 But it makes all the difference if you have more than one event structures in the VI.

---

Your problem is not the front panel locking, but the misguided coding that places slow code inside event structures. Such code should execute in parallel (e.g. using a queues) to make sure the event structure is ready as quickly as possible.

Events should not contain slow or interactive code.

[Ravi_Beniwal]

Hi altenbach, this was not really my problem. I was merely giving a scenario to clarify the difference between using front panel locking or not, to conclude this thread. This was, by no means, recommendation on putting slower code in event structures.

[Lucither]

Hi All,

Must admit that as i normally use a producer/consumer loop in situations like this i have never actually come across this as problem and am surprised at this behaviour. I like others here thought that locking the front panel stopped pressed events from also queuing. I played around with the given example and found that even if you 'disable' button 2, whilst button 1 event is occurring, and 're-enable' when exiting if you have the 'lock front panel' checked it will still fire button 2 event (if clicked), if you do not have it checked then it will not. It seems that all locking the front panel does is queue the fact a click has taken place but deal with this click after button 1 event, whereas if it is not checked it deals with the click straight away. If you have the fp locked then if you click on the disabled button whilst button 1 event is taking place then its event will still be triggered as the click is handled after this event and the button has been re-enabled. If you do not have the fp locked and you click whilst event 1 is happening the button 2 event does not happen as the click is dealt with straight away and in this case the button is disabled so nothing happens.

Rgs,

Lucither