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

Similar Messages

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

Front panel locked up?

I'm using the System Control UI Suite 2.0 and trying to work with graphs on my VI. Frequently my front panel appears to "lock up". I'm apparently able to move around the front panel, however the front panel graphics themselves do not change location. If I hit "ctrl-A" to select all front control objects, the marquees themselves appear where the control 'should' be. If I close the VI and reopen it, the controls appear where I moved them previously. It's as if the front panel image itself is not updating properly.
This does not appear with other VIs. I can get around it by deleting the graphs, saving the VI, renaming the VI, and reopening it. For whatever reason this sequence restores it. Once I add the graphs and attempt to populate them with data in run time, my front panel locks up again.

Hi Synaesthete,
I am curious, do you see the same behavior when using only the stock LabVIEW controls? Have you tried replacing the UI Control Suite System Controls with the stock LabVIEW controls and seeing if the behavior still exists?
Also, do the controls only lock-up when in edit mode or do the controls become unresponsive while executing the VI as well?
Milan

Panel Close? Event causes front panel to be unresponsive

I'm trying to create a simple program. There is a while loop that generates random numbers just so I can see it's running. An "Exit" button is wired to the exit terminal of the while loop. An event structure is also in this while loop, which catches "Panel Close?" and discards it, then wires true to the exit terminal of said while loop. To be more specific, the exit terminal takes an OR statement that takes the Exit button and this Event Structure boolean as inputs. However, when I run the program, the Exit button doesn't respond, though with highlight execution the event structure part of the program seems to be working. Sorry if I'm bad at explaining, any help is appreciated.
I guess my real question is, how do you properly implement that an exit button stops the loop and clicking the red x or File:Close is ignored and instead does the same thing as your Exit button.
Solved!
Go to Solution.
Attachments:
ex1.vi ‏10 KB

For applications that require a user interface I prefer to use a producer/consumer architecture. The producer loop with the event structure essentially does nothing but deal with the UI. It will process UI events as well as provide the ability to update the UI. The consumer loop(s) do the actual work. These loops are generally some form of a state machine but they allow messages to be passed from the producer loop for control purposes. Most common are start, stop and exit events. This type of approach allows your UI to be very responsive to user input. Even though your application may take time to shut down cleanly you can immediately let the user know you are going into shut down mode. They know you receive their input and are working on it. This prevents them from pressing the stop button multiple times. If your shut down does take a very long time make sure you provide regular updates to the user informing them you are still running and not simply hung.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

Front panel locks up

When this vi nears completion it reaches this part of the code and waits for a final comment and for the user to close panel so the iv will finish and close. About 50% of the time it works. When it doesn't the VI is totally locked up and I have to abort out. What would cause this FP to lock up and refuse input?
PaulG.
"I enjoy talking to you. Your mind appeals to me. It resembles my own mind except that you happen to be insane." -- George Orwell
Solved!
Go to Solution.
Attachments:
overview lockup problem.png ‏18 KB

Not sure how this can happen, but one debugging technique is to add an indicator to the loop counter. (and add a +1 between the 'i' and the indicate to see it's started the first run.
It might be that some of the inputs are not ready! (I heavily suspect the numeric array!)
You can try this by placing a breakpoint on every incoming wire, you should all the breakpoints before your freeze.
Another point to try is to set the timeout of the read queue to 100 ms, and remove the OpenG wait function.
That prevents you from loosing messages! When there are more than 1 message per 100 ms. you might loose messages.
For instance:
T=0 ms : start loop
T=0 ms: Read Queue finishes
T=10 ms: Add message 1
T=30 ms: Add message 2
T=100 ms: Iteration 0 finishes
T=100 ms: Read queue finishes and returns message 1
T=120 ms: Add message 3
T=130 ms: Stop pushes
T=150 ms: Iteration 1 finishes
T=150 ms: Read queue finishes and returns message 2
T=200 ms: OpenG wait ends, Iteration 2 finishes, and terminates loop
So your queue has 1 message in backlog, and you had an additional 70 ms wait after the push of the stop button. (this varies between 50 and 100 ms.)
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!

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.

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

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 .

Malfunction of Event Structure?

Apparently, an event structure keeps listening to events even if the structure should be inactive because it is located in the inactive case of a case structure. See the attached simple example.
Any explanations, comments or whatsoever? Is it yet another bug or a meaningful feature of LabVIEW?
Thanks,
Peter
Solved!
Go to Solution.
Attachments:
Misbehaving_Eventstructure.vi ‏16 KB

ThHagel wrote:
1: it executes the event structure independend of the skip_event_structure input
The event is not skipped. Events don't adhere to dataflow, so you are well advised not to bury them inside case structures.
ThHagel wrote:
2: the front panel stays locked after the value change event occurred (the lock frontpanel feature is enabled in the event structure)
If the "lock front panel" is enabled, the front panel wil lock until the event completes, which is this case is "never". It will be locked forever because the event structure is not in the dataflow.
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 .

While loop with stop button within event structure locks up front panel.

I am not sure if this is a bug with my program or a bug within LabVIEW. If you believe that this is a bug with my program then I will post my program to be looked at.
The problem I am having is there is a while loop within an event structure that fires when a particular value changes. Once the "Activate" button is pressed the while loop within the event structure starts going with a polling frequency of 1hz (1000ms wired to the "wait till next ms multiple" vi). There is a "Deactivate" button that is wired to the stop control of the while loop and an outter while loop that resets the event structure so that the activate button is being listened to again.
Once inside the while loop, however, none of the button are responsive within the front panel. The VI continues to run, and only 60% of my CPU is being consumed, but none of the button or scroll bars work. The only way for me to terminate the program is with the "Abort" button next to the "Run" button. If I remove the event structure so that the while loop in question runs as soon as the program starts, the front panel remains responsive. I've inserted probes within the while loop and verified that it is not running prior to the "Activate" button being asserted, and it is running after the assertion of the "Activate" button with the expected polling frequency set by the "wait till next ms multiple" vi.
Can anyone help? Do I need to post my code?
-Nic

It is typically not a good idea to stall an event structure by placing loops inside event cases. What good is an event structure if it is not free to repond to events?
Have a look at some alternative solutions, such as in the following link:
http://forums.ni.com/ni/board/message?board.id=170&message.id=224817#M224817
LabVIEW Champion . Do more with less code and in less time .

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

How can i use the same front panel graph in more than one events in an event structure?

i want to display the signals from my sensorDAQ in a graph.but i have more than one event in the event structure to acquire the signal and display it in the graph.the first event is to acquire the threshold signals and its displayed in the graph as a feedback.after the first event is executed, i will call the second event,where the further signals are acuired and compared with the threshold signals from the event 1.my question is how can i use the same front panel control in more than two events in the event structure?please answer me i'm stuck.
Solved!
Go to Solution.

Hi,
I have attached here an example of doing the same using shift registers and local variables. Take a look. Shift register is always a better option than local variables.
Regards,
Nitzz
(Give kudos to good answers, Mark it as a solution if your problem is Solved)
Attachments:
Graph and shift registers.vi ‏12 KB
graph and local variables.vi ‏12 KB

VI containing Event Structure will not receive front panel events in LabVIEW Real-Time.

Hi again, I'm working in my first UI (attached VI).
It works when running directly from PC. It doesn't when running from cRIO, there's the message "VI containing Event Structure will not receive front panel events in LabVIEW Real-Time". I've been reading and I found that "Event structures on RT targets do not support events associated with user interface objects, such as VI panels or controls. For example, associating the Value Change event with a control does not work. RT targets support only user events".
Is that the problem? If it is, how can I create Mouse Up, Mouse Enter, Value Change (or other user interface events) user events?
If I run my VI in FPGA mode should it run?
Attachments:
HMI.vi ‏33 KB

Since it looks like you are new to the whole RT and machine control, I recommend giving this a good read: NI LabVIEW for CompactRIO Developer's Guide
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Event structure front panel lock

Similar Messages

Maybe you are looking for