Event is there and i got no response

[RavensFan]

You managed to uncheck this box in some of the other event cases!

This would likely solve your immediate problem.  It is not the best solution.  As Altenbach said, reworking your architecture to a state machine would be better.  You really don't want to have a stranded event structure even if you do find your way into the dialog box and uncheck the Lock Front Panel setting.

[ylTSE]

Hi Ravens

thanks for reminding the checkboxes, i did find it and it solved my immediate problem. For the state machine, i am not sure if they can handle the mouse click event, but i will still look into it.

Thanks

[Intaris]

There is another way to solve this problem without having to get rid of locking the FP while handling the events.

LabVIEW offers significantly different functionality for statically linked Events and dynamically linked events (User Events) for the same controls.  If you dynamically link the "Value Change" Events via "Register for Events" then when the Event structure is "Finished" you can unregister for the events, something which the event structure does NOT offer for statically linked events.

See my VI included.

Also, please pass by my idea HERE if you want to stop statically linked events being second-class citizens in the Events world.

PS if you right-click each individual "Value Change" terminal on the "Register for Events" you can choose to have the event handler lock the FP or not (only available if the source of the Event is an UI element).

[ylTSE]

Hi Intaris

This is really an awesome answer and I had never explored to such settings before. thanks for your help.

[altenbach]

---

@ylTSE wrote:

thanks for reminding the checkboxes, i did find it and it solved my immediate problem. 

---

No, unchecking that checkbox is NOT a viable solution. Once the event structure is out of the dataflow, it will continue to queue up events forever, without any chance to ever service them, so if that last loop runs for an extended perion of time and users keep clicking button, youl'll eventually queue up an infinite amount of events consuming resources and gumming up your code, even though the front panel remains unlocked.

Can you tell us a little bit more about your program? What is actually happening in that last loop? Why do you even need it?

It is simply a bad idea to write irreversible one-way code like that. There are better ways!

That last loop is just one state. Place the UI code into an independent loop where you can handle all events at any time, but discard some depending on what state you are in. So please take a step back and look at the design patterns that ship with LabVIEW and use a scalable architecture.

Maybe you should start from scratch and tell us what the program is supposed to do from a user perspective. Currently you are trying to solve a problem that should not even occur if things are designed right. Good luck!

[ylTSE]

Hi altenbach,

yes you are right, maybe i should re-design the whole structure as i used to ignore the structure if the job is done.

Actually this is a sub-vi, at the very last part i hope the user can check the various results as displayed by different indicators on the front panel, and afterwards user can exit when the boolean button is clicked which is controlling the last while loop. As user may click on the controls that have events in the first sequence, the front panel will then be hanged up.

Thanks for the suggestion.