From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

front panel frozen

I have a VI that has been working perfectly for quite a while.  Today the front panel froze.  Nothing in the VI has been modified.  Its environment, LV 2012 with Win 7, has not changed in almost a year.  Although the front panel is frozen, the block diagram is running.  Let me explain.

 

1)  the boolean indicator on the front panel that is data bound to a Shared Variable does not change its value; although according to the Distributed System Manager and the VI writing to the Shared Variable values are changing.

 

2) the string indicator on the front panel does not change its value; although placing a probe on the data line into the terminal for the indicator on the block diagram indicates the value changes.

 

3) the boolean controls on the front panel do not change their value; although the block diagram demonstrates processing in response to the user changing the value of the controls.

 

The properties for the indicators, controls, front panel, are never modified by the VI.  Also, references for these are never passed to a subVI for potential modification.  Any ideas what it happening?

0 Kudos
Message 1 of 8
(3,143 Views)

Someone set defer panel updates True or aborted the vi while it was true.  This can be a real PITA when it happens just like the help file warns about

 

Its probably a good idea to set it false in initialization code if the method is called at all just to avoid that accidental abort issue (or do not show the abort button)


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 8
(3,131 Views)

Jeff's idea with the Defer Front Panel Updates is the more likely issue.  My initial thought was that you have an event structure that isn't being reached.  This usually happens if you put it deep inside of case structures.  So if you hit a button that the event structure is registered for, but the event structure can't be reached (ie run that event case) and the "Lock front panel until event case is ran" is turned on (by default), then the front panel will be frozen.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 3 of 8
(3,087 Views)
I have to turn off aero on all win7 machines to avoid front panel lock up. It is very dangerous as booleans still respond when clicked but show no change. Minimise and re open the panel sorts it out if the aero problem is the cause. NI know about this, so does Microsoft. I really want to find other people who can reproduce this issue, it is probably graphics hardware dependant.
Michael
0 Kudos
Message 4 of 8
(3,077 Views)

@Michael_78 wrote:
I have to turn off aero on all win7 machines to avoid front panel lock up. It is very dangerous as booleans still respond when clicked but show no change. Minimise and re open the panel sorts it out if the aero problem is the cause. NI know about this, so does Microsoft. I really want to find other people who can reproduce this issue, it is probably graphics hardware dependant.
Michael

I had something similar, but in my case the code did keep running and the display did update. The problem was that the input from the UI just froze. This applied to the main VI and to all the subVIs which were in subpanels in the main VI. When it happened, it always happened at the same point in the program - you press the start button, the program enters into the first VI in a specific sequence and then the UI stops responding to clicks, but the code keeps running and the display is updated. It stopped when I disabled the aero display, but I can't offer any specifics. I can say, though, that there's a thread on the LAVA forums with more people who encountered this.


___________________
Try to take over the world!
0 Kudos
Message 5 of 8
(3,068 Views)
I tried to find a dll or .net function to determine if aero was in use but failed to get a good solution. If anyone has such a vi I would like it, and it seems many others would too!
0 Kudos
Message 6 of 8
(3,064 Views)

Hello Michael78,

 

Based on This Example it looks like dwmapi.dll might be what you're looking for.  The DWMCompositionIsEnabled function looks to return the equivalent of the Aero on/off in most cases, although note that DWM is the underlying engine rather than the Aero theme itself (DWM does handle window compositing and redraws).

 

Regards,

Tom L.
Message 7 of 8
(3,019 Views)
Kudo to outlaw for the link. I will try this out as users often forget to disable aero when they get a new machine. I hope thos helps the OP too.
Michael.
0 Kudos
Message 8 of 8
(3,000 Views)