Some frontpanel controls stop firing the Event Structure LV7.1.1

[yocz]

In my main vi,I have an event structure. I created a subVI that also has an event structure. I load the subvi via a subpanel in my main vi. It runs fine for a while. But sometimes after firing events on the subpanel, most but Not All controls on the main VI stop firing the Main Vi's event structure. The Subpanel's subvi event structure always works fine. When I reload the program it works fine again for a while.

[BJD1613]

This sounds to me like your two event structures are stepping on each other. Maybe try increasing the timeout value in the one event structure or by placing a wait in your subvi. This might free up the top level application to read events. Try posting an example of your code. This might help diagnose the problem better. Hope this helps.

[yocz]

Thanx, I tried your sugestions but it still had a problem with some of the main vi's controls. I did some more experimenting and found that the 'mouse down' on my subpanel's control(a table) would cause my problem to happen. I created an event case in my subpanel's vi for the mouse down and set the Discard? to true. Everything works well now.
I think it is an internal labview problem because only some of the main vi controls(buttons) would not generate the proper events.

[yocz]

Here is some minimal code that I have narrowed the problem to. By discarding the mouse event everything works. It took a long time to find. Thanks again for your input.

[KileenC]

Hi dan343422,

How were you using the Mouse Down event previously? More specifically, was the Mouse Down event set to prompt the user with a Dialog Box?

Unfortunately, I was unable to run the Labview program attached since the stop-Go Buttons and Enter type definitions were not included. To make sure that all the necessary files are included when attaching programs, create a library (llb) file instead. In Labview, go to File -> Save with Options... Select Development Distribution and go ahead and put a check-mark for 'Save entire hierarchy' and all three of the fields below that option as well. This will just make sure that everything in your program, whether it was a built-in Labview VI or a custom-made VI, is included.

Event cases that prompt
users with a dialog box can cause unexpected behavior in a VI. For example, if you use a Mouse Down event with a numeric control and configure the event case to prompt you with a Dialog Box, the Event structure responds when you click the numeric control, including the increment or decrement arrows, and displays a Dialog Box. Because the Dialog Box appears while the mouse button is still depressed, the Dialog Box retains focus when you release the mouse button, and the numeric control never receives notification of the change in the state of th emouse button because the dialog box receives the notification instead. After the Dialog Box is closed, the numeric control resumes responding to the previous Mouse Down event and can continue to increment or decrement the control indefinitely, even though you are no longer pressing the mouse button.

To avoid this problem, I would recommend that you not use Dialog Boxes inside Event cases that handle the Mouse Down event. Instead, invok
e the Dialog Box inside the Mouse Up event case or outside the Event structure.

Hope this helps! Have a great day!

Kileen Cheng
Applications Engineer
National Instruments

[yocz]

Sorry, I forgot about that control. I have included a better version.
Thanks, but I was not using a dialog box in the Event structure.

[WVD]

This is the problem that's been bothering me too (big time actually). Thanks for the insight!

First of all I love the event structure and it totally changed the way I program labview. Together with the subpanel addition, it makes for very professional looking programs. Here's my version of the same problem:

I have an event structure on the main VI, and ~20 subpanels. I load various subvi's in the subpanel of the main VI as required. Each subvi has an event structure to handle GUI and incoming user events. I found the problem in the full blown operation, but the problem also appears when I only have one subpanel running, so only one event structure in a subpanel and one event structure in the main program.
I had the problem with a mouse down on a table, and with a doubleclick on a listbox. And indeed I had an attribute node (reference + property node in my case) to the listbox in the event case that handles the doubleclick. When removing the attribute node, no more buttons will stop to respond on the main panel. When you try to readout or access the listbox in any way in the event case that handles the double-click, it fails. It does not matter whether the "Lock front panel until the case for this event is completed" is true or false. After it fails, you have to unload all the code and reload before LV is able to see some of the buttons on the main panel again (LV7.1.1). You do not have to close LV just the VI's.
So my first work-around after reading your story was to drive a user event from the doubleclick event case. That user event case then does the stuff I want to do with the listbox. Did not work. I then added a delay of 1000 ms before accessing the attribute node in the other event case, that worked. I then moved all my stuff back into the original event case and added a delay there before accessing the listbox. 100 ms failed, 500 ms works. So at this point I would tend to unexpected behavior from LV which is timing dependent, not "Operator error".

There is never a problem in any of the ~200 events in the ~20 subpanels. It is always the main panel that is affected. The event handler simply does not "see" some buttons anymore (value change), for example the "mouse down" event would still work for a boolean buttton on the main panel whereas the "value change event" would consistently fail.

[chavezb]

I've run into a similar problem with a sub-panel and event structure.

I have a mouse-down event, in my top level vi, that sends my state machine to a state that calls a sub-vi and inserts it into a sub-panel. I need the outcome of the sub-vi, so I use a call by reference node, which waits until the sub-vi is complete. The problem occurs if any other event causing action happens on the top level while the sub-vi is still running. The top level is waiting on the sub-vi so it can't service the new event until the sub-vi is done, which is ok, but when the action occurs, the top level no longer allows interaction with the sub-panel vi.

I've been able to minimize the effects by turning off the "lock front panel until the event case for this event completes" but it seems that several event causing actions will still cause the sub-panel to "lockout".

I'd appreciate any feedback, this one's got me stuck.

[WVD]

The only "sure fire" way in LV 7.1.1 is to NOT use an event control on the top level vi. That will allow you to use event structures in all your subpanels. After I did that, I have had it working flawless with 20 subpanels or so for the last few months. Each of the subpanels does have an event structure, and I keep all of them going at the same time. I do not stop my subvis when they are removed from the sub-panel because I need to retain the state of each of my GUI components.
So in the topvi, make a polling structure (A while loop that cycles every 100 ms). Hook all things that need to be monitored for change up to a "Check if Changed" Vi that I am attaching. Put all outputs of the many "Check if changed" VI's into a (boolean) array, and find the first true using the search array function. That gives you a number that you can use to execute a case for each changed control. In case there is nothing changed, the number is -1. In the case that handles -1 you put the 100 ms timer so things remain speedy.
I think it will be fixed in the next version of LV.