LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why are "Lock Panel" and "Limit Max Instances" in event structures mutually exclusive?

I don't understand why "Lock Panel" and "Limit Max Instances" in event structures are mutually exclusive. Can anyone explain? "Instances" of an event come both from the panel (when unlocked) but also can be generated (signalled) programmatically - why wouldn't I want to do both at the same time?

 

 

0 Kudos
Message 1 of 14
(1,568 Views)

Lock panel defers processing of user actions until event case completes. This will freeze up GUI thread till event completes. I always UNcheck this box.

 

Limit maximum instances of this event... a user clicks the mouse of the GUI in a fast succession, your event would have to fire number of time the user clicked the mouse. Valid when using Mouse down/up of course. I usually leave this the default.

 

Click the Help when your inside of the Event Structure, my comments come from there.

0 Kudos
Message 2 of 14
(1,561 Views)

@richjoh wrote:

Lock panel defers processing of user actions until event case completes. This will freeze up GUI thread till event completes. I always UNcheck this box.

 

Limit maximum instances of this event... a user clicks the mouse of the GUI in a fast succession, your event would have to fire number of time the user clicked the mouse. Valid when using Mouse down/up of course. I usually leave this the default.

 

Click the Help when your inside of the Event Structure, my comments come from there.


No.  (Almost) NEVER uncheck that box - unless you have a very good reason to.  I've never had to uncheck this box to maintain a responsive GUI.  You should not have so much code in any event case that it locks up your GUI for anything more than fractions of seconds.  Having to uncheck this box almost always means poor coding technique.  Any code that is complicated enough to hamstring the event structure like that needs to be rethought of as a QMH (or something similar) so that the event structure is just the traffic cop that directs the dataflow and little else.

 

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 3 of 14
(1,523 Views)

I've never had a situation where I needed to lock the front panel in order to prevent a problem.  I consider needing to lock the front panel a crutch to prevent some other coding logic problem.

0 Kudos
Message 4 of 14
(1,503 Views)

@RavensFan wrote:

I've never had a situation where I needed to lock the front panel in order to prevent a problem.  I consider needing to lock the front panel a crutch to prevent some other coding logic problem.


That's interesting that we both see this flag as a crutch in different ways.  The LabVIEW Caveats and Recommendations says:

  • If no Event structure executes promptly to handle an event and front panel locking is enabled, the user interface of the VI may become unresponsive. You must ensure that the Event structure is in a loop that runs often enough to respond to user interface events in a timely manner or disable front panel locking.

And since I consider putting slow code in an event case poor LabVIEW practices, I stand by my original assessment.

 

Edit:

But that doesn't mean our viewpoints are mutually exclusive.  That flag probably doesn't mean anything to either of us regardless of the way it is set.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 5 of 14
(1,489 Views)

@billko wrote:

@RavensFan wrote:

I've never had a situation where I needed to lock the front panel in order to prevent a problem.  I consider needing to lock the front panel a crutch to prevent some other coding logic problem.


That's interesting that we both see this flag as a crutch in different ways.  The LabVIEW Caveats and Recommendations says:

  • If no Event structure executes promptly to handle an event and front panel locking is enabled, the user interface of the VI may become unresponsive. You must ensure that the Event structure is in a loop that runs often enough to respond to user interface events in a timely manner or disable front panel locking.

And since I consider putting slow code in an event case poor LabVIEW practices, I stand by my original assessment.

 

Edit:

But that doesn't mean our viewpoints are mutually exclusive.  That flag probably doesn't mean anything to either of us regardless of the way it is set.


I agree with you there.    I don't put slow code in an event structure either.

 

Going back to the first line

  • If no Event structure executes promptly to handle an event and front panel locking is enabled, the user interface of the VI may become unresponsive. You must ensure that the Event structure is in a loop that runs often enough to respond to user interface events in a timely manner or disable front panel locking.

We both do the blue part.   If a programmer does that part, then it doesn't matter if the locking is enabled or not.

 

So let's analyze what happens if slow code is put into an event structure, which is something a new LV user tends to do.

 

1.  Non-locking:  The event structure will accumulate a bunch of repeated events.  From the code standpoint, that may or may not matter.  From a LabVIEW standpoint, theoretically you could accumulate enough events to crash the program.

2.  Locking:  Those things won't happen, but you'll irritate the user of the LV program as to why nothing seems to be happening.  Most commonly, the program is locked up cold and you can't do anything else and are forced to abort.

 

I find that new users are frequently on the forums complaining about a locked up VI when running something with an event structure in it.  The problem is they stuck a while loop in the middle of the event case that requires some other user interaction to escape it but they can't do that because the FP is locked.

 

So the default setting of locking the FP seems to get new users in trouble frequently.  I'm not sure that is a good idea.  Either way, long running code is a bad design.  It might be a case that locking the front panel causes some quick immediate pain that forces the programmer to fix the architecture vs. not having pain until some rare set of conditions occur that accumulated events catch up the programmer.  It just seems that the pain that is inflicted is on us as we have yet another message thread to respond to because the user didn't bother to search the forums and find at least one of 100's of messages asking about the same problem.

 

(Just like how many error -50103 messages we see because someone creates numerous DAQmx tasks.  🙄)

0 Kudos
Message 6 of 14
(1,482 Views)

@RavensFan wrote:

@billko wrote:

@RavensFan wrote:

I've never had a situation where I needed to lock the front panel in order to prevent a problem.  I consider needing to lock the front panel a crutch to prevent some other coding logic problem.


That's interesting that we both see this flag as a crutch in different ways.  The LabVIEW Caveats and Recommendations says:

  • If no Event structure executes promptly to handle an event and front panel locking is enabled, the user interface of the VI may become unresponsive. You must ensure that the Event structure is in a loop that runs often enough to respond to user interface events in a timely manner or disable front panel locking.

And since I consider putting slow code in an event case poor LabVIEW practices, I stand by my original assessment.

 

Edit:

But that doesn't mean our viewpoints are mutually exclusive.  That flag probably doesn't mean anything to either of us regardless of the way it is set.


I agree with you there.    I don't put slow code in an event structure either.

 

Going back to the first line

  • If no Event structure executes promptly to handle an event and front panel locking is enabled, the user interface of the VI may become unresponsive. You must ensure that the Event structure is in a loop that runs often enough to respond to user interface events in a timely manner or disable front panel locking.

We both do the blue part.   If a programmer does that part, then it doesn't matter if the locking is enabled or not.

 

So let's analyze what happens if slow code is put into an event structure, which is something a new LV user tends to do.

 

1.  Non-locking:  The event structure will accumulate a bunch of repeated events.  From the code standpoint, that may or may not matter.  From a LabVIEW standpoint, theoretically you could accumulate enough events to crash the program.

2.  Locking:  Those things won't happen, but you'll irritate the user of the LV program as to why nothing seems to be happening.  Most commonly, the program is locked up cold and you can't do anything else and are forced to abort.

 

I find that new users are frequently on the forums complaining about a locked up VI when running something with an event structure in it.  The problem is they stuck a while loop in the middle of the event case that requires some other user interaction to escape it but they can't do that because the FP is locked.

 

So the default setting of locking the FP seems to get new users in trouble frequently.  I'm not sure that is a good idea.  Either way, long running code is a bad design.  It might be a case that locking the front panel causes some quick immediate pain that forces the programmer to fix the architecture vs. not having pain until some rare set of conditions occur that accumulated events catch up the programmer.  It just seems that the pain that is inflicted is on us as we have yet another message thread to respond to because the user didn't bother to search the forums and find at least one of 100's of messages asking about the same problem.

 

(Just like how many error -50103 messages we see because someone creates numerous DAQmx tasks.  🙄)


I see exactly what you are getting at.  I guess it all depends on whether you think pain is good for the soul or not - and to who experiences it!  😄  Thanks for your point of view.  It makes me reconsider my opinion.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 7 of 14
(1,478 Views)

Whether you put fast or slow code in the Event structure when it fires, there could be all kinds of situation where your code comes to a halt. A resource may not be available, i.e. a HD, a test instrument visa handle, other operation that use the UI thread (drawing/plotting) or even dark matter :^).  In this situation your mouse will give you the "hour glass icon" waiting till this event fully completes. 

 

Assuming multiple apps and the Labview code is running, leaving it UNchecked removes the chance of mouse freezing up, even when my event Labview code is fast but there is a bottle-neck elsewhere.

0 Kudos
Message 8 of 14
(1,424 Views)

@richjoh wrote:

Whether you put fast or slow code in the Event structure when it fires, there could be all kinds of situation where your code comes to a halt. A resource may not be available, i.e. a HD, a test instrument visa handle, other operation that use the UI thread (drawing/plotting) or even dark matter :^).  In this situation your mouse will give you the "hour glass icon" waiting till this event fully completes. 

 

Assuming multiple apps and the Labview code is running, leaving it UNchecked removes the chance of mouse freezing up, even when my event Labview code is fast but there is a bottle-neck elsewhere.


Interesting.  I never considered something hogging the UI thread as blocking the event structure.  I don't think the UI thread would block the event structure, though, according to this (admittedly old) topic.  But all the other scenarios would be examples of code I wouldn't put in the event structure.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 9 of 14
(1,413 Views)

Going back to the original post.

 

If the front panel is locked, why would you want to get away with sneaking around it with either a value signaling or a generate menu/ mouse/user event node?  And what was NI thinking when they failed to automatically enclude Set/Unset Busy when locking the FP anyway?  Users have been banging mice on their desktops since that poor UX oversight originated.

 

The bandage for THAT was to let the developers choose to avoid locking the FP when they shot themselves in the foot.  OF COURSE, that loaded the other gun! Letting the user queue up any number of events that are just waiting to get processed.

 

The workaround for this was to add that limit number of events support ( not available in LabVIEW 6i)

 

So, to ensure that you can only shoot 1 foot at a time, the options are correctly mutually exclusive. 

 

My take: If you're asking that question, you should be questioning your code instead.   Follow the advice previously shared by Bill and RF


"Should be" isn't "Is" -Jay
Message 10 of 14
(1,402 Views)