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

Similar Messages

  • 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.

  • 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

  • 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

  • Disable main vi front panel

    Hi,
    I have a main vi and a subvi which is opened from the main vi. Main vi is maximized (takes all screen) and subvi is small one. My desired behavior is: the main vi opens the subvi, main vi must be visible in the background, but it must not collect any event (e.g.. If button on the main vi is clicked when the sub vi is opened).
    I know that can be achieved with setting the subvi to modal, however I do not want to do that (because subvi opens also some other windows, ...).
    Is there any other way to prevent the main vi to collect events while the subvi is opened (e.g. To disable whole front panel at once)?
    Thanks!

    Hi,
    As an alternative to a modal dialog, you can use the VI Server "version" of the modal functionality, by using the FP.IsFrontmost VI property.
    How Do I Configure My LabVIEW Application Window to Always Be on Top?
    Alternatively, you can programmatically "take" focus from your subVI once, when it launces by using the Application / Bring To Front invoke method.
    You can also programmatically give the Focus to the subVI from the main VI, that is a bit more compicated as you need a VI reference to your SubVI (See Calling a VI by Reference). Then you can for example use FP.IsFrontmost again.
    Best Regards,
    T Simon
    National Instruments
    Applications Engineer
    Certified LabVIEW Developer - Certified TestStand Architect

  • 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

  • 6650d Flip front panel switch problem

    Can anyone tell me how I disable the front panel switches on my Nokia 6650d flip. Whenever I put this in my pocket the switches are activated whenever I walk: resulting in an annoying beep. It also flattens the battery.  It completely negates the point of a flip phone. The phone is OK I just need to know how to disable these annoying buttons.  Can anyone help?

    To lock the keypad in the standby mode, press the left selection key and * within
    1.5 seconds. To set the device to automatically lock the keypad after a certain
    time, select > Settings > Phone sett. > General > Security > Phone and SIM
    card > Keypad autolock period > User defined and the desired time.
    To unlock the keypad, select Unlock, and press * within 1.5 seconds.
    When the device or keypad is locked, calls may be possible to the official emergency number
    programmed into your device.
    To lock the cover keypad, slide your finger on the the left cover touch key and then
    the right cover touch key within 1.5 seconds. If you have locked the keypad from
    the cover display, and your device goes to sleep mode, you first need to press the
    camera key to activate the cover touch keys. To unlock the cover keypad, slide
    your finger on Unlock (left cover touch key), and then OK (right cover touch key)
    within 1.5 seconds.
    If  i have helped at all a click on the white star below would be nice thanks.
    Now using the Lumia 1520

  • 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

  • Disabling the ront panel

    Hi guys, is there a way to disable a front panel, like how you can disable a control?
    I want to freeze some of my VI's say, after 5 minutes of inactivity.
    Tyhanks inadvance for the help!!

    Another option is to use a modal popup, like a logout.
    I do this in state machine architectures when user login is required, when the system has been idle for too long goto the login state, in this state I hide the FP and popup a modal login screen.
    Paul Falkenstein
    Coleman Technologies Inc.
    CLA, CPI, AIA-Vision
    Labview 4.0- 2013, RT, Vision, FPGA

  • Audio Front Panel with MSI

    1.Product Type: Motherboard MSI G965M MS-7241 with integrated Realtek audio and updated driver for Windows Vista - 6.0.1.5331
    2.BIOS version: AM v. 1.1, 2006-10-23
    3.External VGA Type: NVIDIA GeForce 7600GS
    4.CPU Type: Intel Core Duo 6400
    5.Memory Type: Dual Channel 2GB
    6.Power Supply Type: 400W
    7.Operating System: Windows Vista
    8.Problem Description: Front panel audio connectors 3,5 mm plugs are not operating regardless they are connected to JAUD1 port. Plugging with the headset with microphone doesn't gives any effect - they are unvisible by the system.

    Does the case support HD Audio"Azalia"?
    Have you tried to disable the front panel jack detection under analog connection settings (click on the wrench) in the Realtek HD Manager?
    This thread may or may not help: https://forum-en.msi.com/index.php?topic=105631.0

  • How to change front panel indicator properties such as background color or enable/disable programmatically?

    Is it possible to change the properties of a front panel indicator such as background color or to change from enabled to disabled-grayed out programatically in response to limit conditions or a time-out?

    "Disabled" means that the control/indicator will not respond to a user operation. However, the displayed data can still change. What you want to do can be easily achieved using a case structure : wire your boolean to the case input, and put your indicator in the "True" case condition. That way, it will be updated only when the digital input is set to true.
    CC
    Chilly Charly    (aka CC)
             E-List Master - Kudos glutton - Press the yellow button on the left...        

  • How to lock a pane within front panel

    Hello,
    i am trying to lock a single specific pane of my front panel while handling an event.
    or the inverse
    in the event structure, one can lock the front panel while performing the event. i would like this to happen, in order to avoid queuing other user events in the mean time.
    except for some commands, which i all put in a single pane (like a taskbar), and which includes important features that should be accessed at all time.
    however i could not find any property of the pane or the front panel that allows me to do so.
    any idea?
    ... And here's where I keep assorted lengths of wires...

    Thanks  Partha,
    i have looked at this thread before, did not think it related too much.
    if i want to set busy, i still cant use the pane 1 of my front panel. or, the inverse, if i set controls to "disable" i would have to do it for all the controls in the pane 2, for every event that is fired. anyway it is reported there to not work as desired.
    i think we might have here a suggestion for improvement:
    i could not find anywhere except in the options for specific event, the option to lock the front panel. to my taste this should be an avaible property node. then, this option would also automatically exist for every pane in the front panel.
    what do you think?
    in the mean time, i still need a workaround. an idea i had, but makes my code more complicated, is to implement an external vi that would be always on top, and would be as the pane 1 in my curent vi. i would not like to do this actually...
    ... And here's where I keep assorted lengths of wires...

  • Event structure front panel lock

    hi, I have a mouse down event for pushbutton on the front panel to trigger an event. The event structure is under a while loop. However, I checked 'lock FP during the process' but the pushbutton actually registers the mouse click. i.e. once i click the pushbutton during the event(which is supposed to be locked), the event will be triggered again automatically after the current round.
    Does anyone know how to fully lock the button? I even add in property node to disable the button in the beginning of the event case but it doesn't work as well.
    Thanks a lot.
    Cheers,
    SSR 

    Hi,
    The option is to 'Lock the front panel until the event case for this event completes'. If you have this checked, then all other controls are locked until the event triggered by the mousedown completes.  It does not prevent the event from registering in the first place. The mousedown will still register and it's event code will execute regardless if this checkbox setting (unless another event is being processed at the time).
    Mousedown also registers if you disable the control either programatically or via the menus - you need to change the event to 'Value Change' instead of Mouse Down. If you do this and programatically alter the enabled stated of the control, you can control whether the event is processed or not.
    HTH
    Steven
    edit: stevem181 beat me to it and in fewer words too
    Message Edited by Steven_G on 11-02-2009 10:33 AM

  • Pressing on the Table Control locks the front panel in a certain state

    Hello everyone!
    I have following problem. I have a very simple state machine with two cases. In the Idle case there is an event structure receiving input from a Table Control. When pressing Run the Vi enters the Run state. To exit the RUn state I have a Finish button, but IF I during the running state press anything on the Table Control the entire front panel will lock. Disabling the Table Control in the running state doesn´t help in the same way it helped for Button 1 and 2. Any help would be appreciated. I have tried unsuccesfully with the Registering and Unregistering event functions.
    Attached is a simplified version of the problem. Thanks in advance.
    Solved!
    Go to Solution.
    Attachments:
    Event lock problem.vi ‏22 KB

    Hi, RealBjörkis !
    I ran your VI and I saw a few problems, try to keep your controls outside the events structure, also do what said P@Anand previously.
    Here is your VI with some corrections. (Hope it fix the problem)
    Good Luck.
    Attachments:
    Event lock problem.vi ‏23 KB

  • Front panel of SubVI locks on 2nd call

    HI!
    I'm calling a SubVI and pass a Boolean Reference to this SubVI. In the SubVI I'm executing a While loop. The stop condition is the value of the boolean control in the VI that calls the SubVI. (Boolean Refnum + Property Node: VALUE connected to while stop condition)
    Mechanical Action of the Boolean in the calling VI is: Switch when pressed.
    For the first time this will be executed it works fine. But the 2nd time the SubVI is called. The Front Panel of the calling VI where the stop button is located will be locked.
    Does anybody have an idea why this happens and how I can solve that problem?
    ANDY

    I tried what you described, using LV 7.1, and I have no problems running the vi over and over again. See the attached examples. Ref1.vi calls Ref2.vi and passes the Boolean reference to it.
    - tbob
    Inventor of the WORM Global
    Attachments:
    Ref.zip ‏21 KB

Maybe you are looking for