Unexpected effect of Lock Front Panel in Event Structure

I have been using LV intensely for only a short time, although I have dabbled with it many times since its first appearance. The "problem" that I have had may well be the intended behaviour, but it just seems unintuitive to me. I'm writing a small application to take measurements from a USB instrument. I have already written a basic driver for the instrument, which the application calls, and the driver is working as expected. In the application, the user can configure various settings and then click an Execute button to transfer them to the instrument. The click event is handled in an event structure along with other events. Since some of the instrument operations take an appreciable time, the first action that occurs in the click event case is to disable the Execute button using a property node so that further clicks are ignored until the operation completes, at which time the button is re-enabled.
When disabled, the Execute button is grayed out as expected and clicking it has no visual effect. However, it seems that clicks made during the disabled period are still queued and acted upon when the button is re-enabled, causing the operation to be repeated.
It is the solution I have found that seems unintuitive to me. The Lock Front Panel check box was checked (by default) for the click event, and I assumed that this would be the correct setting. However, unchecking the Lock check box actually makes everything worked as expected. Click events occurring during the disabled period are now ignored or discarded. I'm not suggesting that this is a bug, but I'm interested to learn why it happens, if anyone can explain. I have attached a picture of a simplified version of the event case.
Attachments:
Sample.png ‏7 KB

I would say what you see is expected behavior, even though it's a bit complicated.
The "Lock front panel until the event case for this event completes" option will only defer clicks and other things generating events until the current event handler completes. So this means that the click is placed in a queue and only evaluated once the event is finished. At this time, the button is no longer disabled, so an event is generated.
When the "Lock front panel until the event case for this event completes" is not checked, the click is immediately evaluated, but it's happening on a disabled control, so it does not generate an event.
From the LV help:
By default, when an event enters a queue, LabVIEW locks the front panel that contains the object that generated that event. LabVIEW keeps the front panel locked until all Event structures finish handling the event. While the front panel is locked, LabVIEW does not process front panel activity but places those interactions in a buffer and handles them when the front panel is unlocked.
Note If an event case that locks the front panel takes a significant amount of time to execute, consider using the Set Busy function or displaying a dialog box to notify the user that the front panel is locked.

Similar Messages

  • Using a "menu ring" feature on the front panel with event structures

    hello - right now i have many event cases controlled by many "ok buttons". i would like to use a menu ring on the front panel to save space from all those buttons, but i don't see how it will work with all the individual event cases. currently each event is tied to a single button, and the menu ring acts as one thing on the block diagram so i can't tie an event to a choice in the menu. any suggestions? thanks....

    Alternativley, you could use an enum control instead of a menu ring. It will name the cases according to the selection automatically.
    If you want to use a menu ring and strings, you could do something like in this image.
    Message Edited by altenbach on 02-09-2006 01:43 PM
    LabVIEW Champion . Do more with less code and in less time .
    Attachments:
    RingText.png ‏3 KB

  • Lock front panel until the event case for this event completes

    A Dynamic Event is a filtered event? Is this why "Lock front panel until the event case for this event completes" is not shown on Edit Event window dialog? I use Dynamic Event so I can subvi the event structure.
    I need stop my app from locking the FP whenever the user double clicks on the numerical array value (<-- the FP freezes the mouse and renders it useless) and stops the value from ever being changed. This event is registered for Value Change (not mouse up or down) and I get a locked mouse. As yet in the UI, no value changed occurs but I get a locked mouse. A LV bug?
    Trying to KISS, I can see this fixing this by moving ONLY the value change event to the top level VI instead of a dynamic registered event in a subVI. This will give me the option to NOT "Lock front panel until the event case for this event completes" .
    Solved!
    Go to Solution.

    richjoh wrote:
    Thx, Ben that fixed the problem when I unchecked "Lock panel...".
    So it appears LV locks the panel during runtime once the Dynamic Reg Events is on BD and it doesn't matter if your case to handle the Reg Events is created or NOT... interesting. That's why my mouse persisted to "freeze up" although I deleted the case for my FP array.
    Its situation like what you described that has given me many insights into how LV actually works. In one of my bbuggy VI's I found that a class wire can run a million miles through multiple sub-VI queues etc but the data itself is only touched when it has to be touched. in my case it was a crash while trying to write bogus class dat to a TDMS file.
    I am glad you are back on course.
    Ben
    Ben Rayner
    I am currently active on.. MainStream Preppers
    Rayner's Ridge is under construction

  • Disable/Lock Front Panel Programmatically

    Hello
    I have a huge project with a bunch of boolean controls. Each boolean triggers an event. So when an event is triggered, I disable all other booleans to avoid any event lock up.
    There are cases where I have to disable ALL the boolean, for ex. when saving, I disable all controls till a report is generated. Is there anyway I can lock or disable the front panel programmatically rather than use property nodes to disable them ? I am losing a lot of my real estate and VI becomes really huge (1.41 MB so far, just the top level )
    Thanks !!
    Kudos always welcome for helpful posts

    Maximus00, like you, I have a huge VI (complex UI with controls/indicators), It is now 2.5 MB in LabView 8.20 (in 6.1, it is about 5mb).  I'm looking for the same thing, that is how to disable the Event Structure "locking front panel".   Currently, I disable all 50 events for this feature, but this is cumbersome, tedious, and should be a better way.  I came across your post and wish LV had a way to programattically disable it, via a property node.    The VI I am working is large, and will most likely be used be maintained by multiple developers so it is critical that there is some way to inhibit the "locking front panel", anytime they add or edit an event.   It is definitely NOT a good thing to have the VI lock up!  By Programmatically disabling all of the event structure's locking front panel, this would protect the VI code from locking up, if a new developer is unfamiliar with the code.
    If anyone knows a way to Disable/Lock Front Panel Programmatically let us know!!
    -crazycliffy
    - crazycliffy

  • Locked panel using event structure

    Hi!
    I'm using an event structure block to run a sequence only when a value of a control has changed.....when I edit this event I set the option NOT to lock the front panel.
    When I run the vi's I can change the controls of the front panel......but all the code outside of the event structure block does'nt run....what i have to do?
    I've attached a simple example.....boolean2 can change his value but the code is not executed
    Thanks in advance
    Larson
    Attachments:
    example_event_error.vi ‏42 KB

    hi there
    the while-loop waits for all the code contained in it to finish until it turns again. the event-structure has no time-out case defined, so if "Boolean" dosn't change it waits eternally. that's why the "Boolean 2" seems to be locked, because this code is not executed any more until the next turn of the while loop.
    add a timeout-event (event source = Application) and connect the event timeout (e.g. 100 ms). be aware that the reaction to a change of "Boolean 2" takes up to timeout ms. another option is to put the code inside the timeout-case.
    best regards
    chris
    Best regards
    chris
    CL(A)Dly bending G-Force with LabVIEW
    famous last words: "oh my god, it is full of stars!"

  • Lock front panel with has titel bar?

    How can I lock a front panel that has a title bar?
    I do not want that the user
    - close the window --> ok, vi-property
    - resize the Window --> ok, vi-property
    - minimize the window --> ok, vi-property
    but:
               I also want, that the user can't move the window using the titel bar
    I do not want to poll permanently the windows-position.
    Any idea?

    Hello zav,
    via vi->property node you can also set the window size. So switch of
    closing/resizing/minimizing in the vi properties dialog and do the rest
    in a small while loop parallel to your main program (permanently set
    the window size to the size of the screen).
    Attached is a picture of a sub-vi calculating the window position
    regarding to screen size. The output is wired to a property node
    'Frontpanel Window.Window Bounds'. Hope this helps...
    Best regards,
    GerdW
    CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
    Kudos are welcome
    Attachments:
    WindowSize.png ‏4 KB

  • Event Structure hangs VI

    I am using Tab Controls in my VI, and want to reset some Button
    Controls (using property nodes) when the tab controls change value. So
    i have tried to use an event structure which contains a FALSE constant
    wired to the VALUE property of several Button Controls. It works just
    fine, the only problem is that i cant operate any buttons or stop the
    VI from the stop button. It seems like the event structure hangs the vi.
    I guess there is a simple solution to this problem, but i cant find it and i am getting desperate... Please help!
    Attachments:
    event.jpg ‏29 KB

    Hello Vatoloco,
    I can't give a short (correct) answer but:
    The vi structure will always get every event. If you have selected to 'lock front panel until event structure done' (as is by default) for this event it means that :
    The front panel is unresponsive until the event has executed
    This is a tricky thing because if the event structue isn't executing, it locks the front panel. A quick check for this is to deselect this option.
    If that works you have to redesign your vi. Have a look at the design patterns that ship with labview. Or you could look with high-lite executing where your VI 'is' when you change the tab control.
    Ton
    PS For a more correct post, search this forum with a broader timespan (let's say 12 months or so) you're not the only one!
    Message Edited by TonP on 04-21-2006 01:43 PM
    Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
    Nederlandse LabVIEW user groep www.lvug.nl
    My LabVIEW Ideas
    LabVIEW, programming like it should be!

  • Dataflow Conflict appearing on the front panel

    Hello,
    my vi is almost done but I still have a problem with the front panel. I think it's about data flow conflicts in my vi.
    When you run my vi, you will see the pop-up window to ask you about putting a file path, adjusting the units, selecting data to save and plot. Then you might want to change the units, turn on-off all light and ok buttons to choose which data you want to save. Then click RUN.
    The problem is; supposedly all buttons are on as default, if you turn off some saving or plotting buttons for not choosing to save, then click RUN, after that all buttons are on again even though you turned them off before running. They should stay off if you didn't select to save them. The condition of the main data stream always goes back to be the same before running (only light and ok buttons).
    Do you have any ideas how to solve this problem?
    Thank you in advance
    Solved!
    Go to Solution.
    Attachments:
    Value Measurement Project.lvproj ‏2 KB

    You have what's called a race condition which commonly creeps into programs that use local variables.  If you look at your first while loop you read in the current "Main Data Steam" value from the control and store it in a shift register.  After the event structure exits you write the value from this shift register back into the control and in the process overwrite any changes the user may have made.
    One quick and dirty solution would be to handle the Value Changed event for "Main Data Stream" in your event structure to update the shift register whenever the user changes values in the control.
    A better solution would be to get rid of the shift registers and move the local variables into the event structure.  As long as the "lock front panel until event completes" option (I'm not sure of the exact wording and I'm working in LabVIEW Base at the moment so I can't check it) is selected it will ensure that you don't run into a race condition (you know the value can't change inbetween you reading in the value and you updating the control).
    Better yet would be to avoid local variables wherever possible.  This is just general advice and not something I can make much more tangible without knowing the details of how you want your application to behave.
    Hope this helps,
    Simon

  • Locked controls on new tab after finishing event structure

    Greetings All,
    My first question for the forum.  I found a few posts which had similar issues but I still can't seem to figure this one out.
    This program creates a temperature profile and it's within a much larger program where I want the user to be able to cancel, continue, go back a step, etc.  It all works fine until I leave the event structure loop and go to the verify tab.  The user should be able to continue or cancel but the buttons will not press.  I believe the event structure is locking the front panel but I turned off the lock for that case and still no go. 
    I've attached the LLB, please check it out.  Any help will be most appreciated.
    Regards
    Using LabVIEW: 7.1.1, 8.5.1 & 2013
    Attachments:
    TempProfiler2.llb ‏575 KB

    Hi,
    The answer is almost in the question, just go to the event structure and disable the option "lock front panel until event completes"
    Message Edité par TiTou le 06-30-2006 09:18 AM
    When my feet touch the ground each morning the devil thinks "bloody hell... He's up again!"
    Attachments:
    Clipboard01.png ‏435 KB

  • Frontpanel freezes when an event of an already closed event structure occurs

    Hello,
    I´d be very glad if someone could explain to me the behaviour of the attached short and simple vi.
    If you press the OK button #1 once and then the OK button #2 the vi finishes, but if you press the first button more than once before pressing the second button, the front panel is locked. In both event structures, the feature "Lock front panel until the event case for this event completes" is enabled. If it is disabled the front panel is not locked after pressing the first button twice. What I do not understad is why if the feature is enabled the front panel locks after pressing the first button twice. I would think that after the loop containing the event structure closes, the event case should definitively be completed.
    Attachments:
    Event.vi ‏12 KB

    This is expected behavior.
    If you look at your event configuration, both events are set to "lock front panel until event completes". If you fire the second event first, the FP locks and you cannot trigger the first event any more.
    Quick and dirty solution: uncheck "lock front panel...".
    Better solution: learn about dataflow and proper program design. What you are doing here is not a good program architecture. Deadlocks, too sequential,  event structures that cannot be serviced immediately due to dataflow dependency, etc.
    Maybe you can tell us in a more general way what you are trying to do.
    LabVIEW Champion . Do more with less code and in less time .

  • Event structure inside a case structure

    Hi,
    I've got a problem w/ my porgram, and managed to boil it down to this
    simple example.  The program basically hangs if you change the
    Numeric value when the boolean is false.  I don't understand
    why.  I suspect it has to do with the way event structures are
    treated, but if someone cou please explain this I'd be greatful.
    Also, now imagine I have 7 numeric controls, handled by 7 cases in that
    event structure, and I actually want to do things in response to the
    value change for each.  Can someone suggest an elegant way to do
    that?  I thought what I had here was a good design, but apparently
    not.
    Bjorn
    (I'm using labview 7.1)
    Attachments:
    EventInCase.vi ‏24 KB

    It is generally a bad idea to place event structures into cases. Events structures need to be able to breathe.
    Maybe you can redesign your program and place the case structure inside the event structure, for example? (Also have a look at the online help for the event structure, especially the link "caveats and recommendations for using events ".)
    Detailed analysis:
    Your event case for the numeric is set to "lock front panel until event completes".  If you change the numeric while the case is false, the evet structure cannot execute, so the front panel locks forever. The observed behavior is as expected. All clear?
    In addition, if the case is false, the main loop spins at nearly infinite rate, consuming all available CPU. Place a small wait to be more cosiderate to everything else running on your rig.
    LabVIEW Champion . Do more with less code and in less time .

  • Change the condition in event structures

    Hi all,
    I am a student, currently doing a project. I'm very new to labview and I don't really know much of the function in labview. Anyway, I have this timer made using event structure if I'm not mistaken (I downloaded this timer from one of the post in this forum). This timer will start at 0s, count to 20s, then stop. So what can I do to change the end time of this timer?? Let's say stop at 50s??
    Attached is the program. Kindly please explain to me or modify the program and attached back as a reply. I've been trying to figure it out from the help function, but still don't understand.
    Thank you very much in advance!!!
    Solved!
    Go to Solution.
    Attachments:
    TIMER s.vi ‏13 KB

    Hi,
    Thanks for your inquiry. The VI attached uses a couple of programming structures: While loop, Event structure and Case structure. What you would have to change is actually the case structure. Before we go to that, let us go through the different structures. Open up the block diagram by going to the Menu bar of the front panel and navigate to Window->Open block diagram.
    The While loop is like a Do Loop in text based programming. It will execute until a condition is met. From the attached VI, it stops running when you click the exit button.
    The Event structure is a structure which consists of subdiagrams. The structure responds to interactions with front panel objects. For example, if you click the start or stop button in the front panel, the event structure will switch to a case which corresponds to this interation. In the attached VI, the case, which corresponds to intreaction with the start or stop button, is called  "Start", "Stop": Value Change. Each case will contain an event-handling routine.
    Case structures are like switch statements in text programming. Take a look at the "Start", "Stop": Value Change event. It contains a routine which consists of a case structure. The case structure responds to the input terminal called Start (which is actually the start button on the front panel). The case structure switches between cases according to this input. To view the different cases just cycle through the case structure by clicking the left and right buttons. There are only two cases: True or False as the input is a boolean.
    Now lets take a look at the VI. Take a look at the "Timeout" case of the event structure. This is where the modification needs to be made. Modify the case structure by editing the cases. Change the numbers in case structures: ..20000 to ..50000  and 20001.. to 50001.. This should do the trick.
    Regards,
    Alan Bong

  • Front panel locks with event structure loop and another while loop

    Hi,
    Why is the front panel locking after changing the value of the "boolean switch" twice? This problem disappears if I uncheck the "lock front panel" option in the event case. However I don't understand why that is the case since the event structure loop has already finished executing.
    thanks

    Do you really want the event handling to stop after detecting the first event? If so then as Christian says the event structure will cause the front panel to lock. What you can do is dynamically register and unregister the events. You right click on the event structure and enable "Show Dynamic Event Terminals" Then  you can programatically register and unregister events.
    Here is your vi modified to do that.
    Edit: Just in case - right click on the control and create a reference. When selecting the source of the event in the structure look under the dynamic section.
    =====================
    LabVIEW 2012
    Attachments:
    event structure test.vi ‏13 KB

  • Tabbed panel panel change event

    Hai friends,
    I wants to fire an event when a tab is activated in a jsf tabbedpanel is there any way to do this please help me

    richjoh wrote:
     As you can see, I am taking the Pane Refnum from the top level VI and dynamic register it to the Event Structure.
    My only guess is this Event Stucture I show is executed inside and an Event Structure...
    Well I don't see that you actually use the Pane Refnum from the top level VI but the following code works for me (I know this is not like yours)
    But I think you got a point with the nested Event structure, this shouldn't be problem IF you uncheck the box 'Lock front panel ...' in the main VI. Checking this box will prevent the UI from be usable and fire events (just what you experience here)
    Ton
    Message Edited by TonP on 10-02-2007 06:21 AM
    Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
    Nederlandse LabVIEW user groep www.lvug.nl
    My LabVIEW Ideas
    LabVIEW, programming like it should be!
    Attachments:
    Example_BD.png ‏6 KB

  • Panel resize event bug?

    I'm having a bit of hassle with a panel resize event.
    For reasons best known to me, I have some parallel loops monitoring certain UI behaviour and reacting appropriately.
    I have noticved that when a loop which is monitoring the "Panel Resize" event stops, (No dynamic registration) the next panel resize will freeze the VI.  It's as if the Event case is not releasing the handle to the "Panel resize" event.
    If I handle the "Panel Resize" event via a dynamic registration and subsequent release, everything works fine.
    This is in LV 8.2.1.
    Shane.
    Say hello to my little friend.
    RFC 2323 FHE-Compliant
    Attachments:
    Freezes.vi ‏22 KB
    Doesnt freeze.vi ‏24 KB

    tst wrote:
    I think this has to do with LabVIEW locking the FP (as configured) even when the event structure should not execute any more. I actually created a simple example of it recently, but saved it in one my projects instead of where I would see it, so I forgot about it. I now dug it up and back saved it to 8.0. You can also simplify this example by removing the value change event and making the key down event lock the UI.
    Message Edited by tst on 11-10-2008 02:14 PM
    Sorry Yair,
    but this is not a bug!, it is explainable behaviour and expected behaviour.
    What happens, the front panel is locked on the second edit. (use exectuion high-lighting) The event structure is always listening for events where it is registered for, even if the event case will never execute, on the first edit (key down) the event is triggered and the VI is locked and unlocked. The second edit the event is triggered again and the FP is locked. Because the event structure can't execute the FP stays locked.
    Shane's behaviour is truly a bug.
    The same behaviour is seen with the 'Pane:size' event. (in 8.6)
    Ton
    Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
    Nederlandse LabVIEW user groep www.lvug.nl
    My LabVIEW Ideas
    LabVIEW, programming like it should be!

Maybe you are looking for