LabVIEW
Event Structure dependency freezes panel
Solved!
The "don't lock panel" is a very (very!!!) poor "bandaid" solution, it does not really solve your problem of your incorrect and highly flawed code architecture.
An event structure will queue up events even it they cannot be handled due to dataflow issues, so you need to solve the dataflow issues!
- In your case, you are waiting for a mouse-down event in the first frame (Which should be a value changed event! Mouse down events are for indicators, not controls!)
- If the ring is changed before the mouse down, it will will be placed on the event queue and you have it configured to lock the panel until the event completes, but it can never complete because the mouse down cannot trigger because the panel is locked. Catch 22!
- Same if you do another mouse down on the button. Since the first event structure has completed, it can never fire again and will again lock the panel.
- If you do the same with locking disabled, the ring event will trigger as soon as the first frame completes (mouse down) and at this point you might have forgotten that you even changed it. Until then, changing the ring has no effect and if you would change the ring a million times, there will be a million ring event accumulated that will all execute in order once the second frame is reached. You maybe get events for ring values that were never intended.
Event structures should never (never ever!!!) be hidden in structures (case, sequence, other event structures, etc.). They need to be ready to handle events and should not rely on dataflow to occasionally get a chance.
This leaves us to the problem you are trying to solve. I am sure once you explain WHAT you want to do (not HOW you want to do it!), we can give you a perfect solutions that is much (much!!!) less complicated.
@samwarr11 wrote:
- This occurs when I have two event structures in series where the ring value change event is included in the second event structure
Don't have 2 Event structures in the same VI.
@Yamaeda wrote:
Don't have 2 Event structures in the same VI.
Most of my code has at least two event structures. There is no problem having several as long as the architecture is fine. For example I have a main value change event for "checkbox X" to do all the dependent math, and a UI helper loop with the same event to update visibility, etc. of other front panel elements). This help separation between UI and math and keeps the main event structure clean.
(One thing to be aware is that discarded filtering events (e.g. "panel close?") will only be seen by one, because whatever event structure sees it first will discard it and the other event structure will never even see it. Easy to code around once we know that 😄 )
So: don't have more than one event structure in the same loop and make sure that each event structure is always ready to react, that events don't contain interactive inner code, and that events complete quickly (<<<1s) on their own.
@altenbach wrote:
@Yamaeda wrote:
Don't have 2 Event structures in the same VI.Most of my code has at least two event structures. There is no problem having several as long as the architecture is fine. For example I have a main value change event for "checkbox X" to do all the dependent math, and a UI helper loop with the same event to update visibility, etc. of other front panel elements). This help separation between UI and math and keeps the main event structure clean.
(One thing to be aware is that discarded filtering events (e.g. "panel close?") will only be seen by one, because whatever event structure sees it first will discard it and the other event structure will never even see it. Easy to code around once we know that 😄 )
So: don't have more than one event structure in the same loop and make sure that each event structure is always ready to react, that events don't contain interactive inner code, and that events complete quickly (<<<1s) on their own.
Yes, exactly. But you know what you're doing. 😄
