LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Faster way to enable/disable front panel objects?

There's probably an easier way, but I create a constant from the ref and put it in the cluster.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 11 of 24
(2,424 Views)

Instead of keeping track of all of the controls that are disabled (so you can turn them back on later), use property nodes to get an array of all references and enable them all at once and then disable the next set of controls. Alternate clicking the Button and Button2 in this example.

 

 

aputman
Message 12 of 24
(2,415 Views)

@CETGirl wrote:

 

I am wondering if there is a better way to handle controls while in an event structure. Here is a common scenario:

 

I have multiple controls on the front panel (buttons, slides, etc...) I use button 'A' to enter an event case that contains a while loop. What i want is for all controls EXCEPT button 'A' to be disabled, because i am using button 'A' as the while loop stop condition (as well as the event case action). Since the event case automatically disables the controls until the case has finished I go in and uncheck this, that then leaves me with a mess of property nodes so that all controls besides button 'A' are disabled. Once the user has stopped the loop by using button 'A', i again need to deal with property nodes to re-enable all of the controls on the front panel.

 

Is there a cleaner, more efficient way to handle things like this?


I am probably one of the guys Ben had in mind when he talked about changing the architecture. You really should not have interactive loops inside event cases. That just gums up the gears.

 

I actually don't understand how you use the button A as the event condition AND as the loop condition. Wouldn't the event fire again when you stop the loop?

 

How many other controls are there?

 

I think it would help if you could attach a simplified version of your code so we get a better idea what the best solution is.

 

 

0 Kudos
Message 13 of 24
(2,402 Views)

@altenbach wrote:
I actually don't understand how you use the button A as the event condition AND as the loop condition. Wouldn't the event fire again when you stop the loop?

I might be wrong, but what if you used the button as a start and cancel to some event?  Say you click and it goes into the event structure where there is a while loop that is polling the button value and if it changes back the software should cancel the operation.  So you may want to disable all controls other than that one button during the operation.  Then enable all controls after the cancel.  I wouldn't have gone with the design of a while loop in an event structure but I can see why organicly written software might turn into that.

0 Kudos
Message 14 of 24
(2,373 Views)

@altenbach wrote:

@CETGirl wrote:

 

I am wondering if there is a better way to handle controls while in an event structure. Here is a common scenario:

 

I have multiple controls on the front panel (buttons, slides, etc...) I use button 'A' to enter an event case that contains a while loop. What i want is for all controls EXCEPT button 'A' to be disabled, because i am using button 'A' as the while loop stop condition (as well as the event case action). Since the event case automatically disables the controls until the case has finished I go in and uncheck this, that then leaves me with a mess of property nodes so that all controls besides button 'A' are disabled. Once the user has stopped the loop by using button 'A', i again need to deal with property nodes to re-enable all of the controls on the front panel.

 

Is there a cleaner, more efficient way to handle things like this?


I am probably one of the guys Ben had in mind when he talked about changing the architecture. You really should not have interactive loops inside event cases. That just gums up the gears.

 

I actually don't understand how you use the button A as the event condition AND as the loop condition. Wouldn't the event fire again when you stop the loop?

 

How many other controls are there?

 

I think it would help if you could attach a simplified version of your code so we get a better idea what the best solution is.

 

 


Here is a VERY simple version of what is going on. As far as how many controls, it depends on the application, some have 10+ others only 4-5. Thanks for all of your help 🙂

0 Kudos
Message 15 of 24
(2,338 Views)

@billko wrote:

There's probably an easier way, but I create a constant from the ref and put it in the cluster.


That pretty much is the easier way.

 

The "other way":

 

Inset a control refnum control...

Select control refnum.png

 

And use this simple and easy right-click menu!

Select VI server class.png

0 Kudos
Message 16 of 24
(2,316 Views)

@CETGirl wrote:
Here is a VERY simple version of what is going on. As far as how many controls, it depends on the application, some have 10+ others only 4-5. Thanks for all of your help 🙂

Here's a very simple modified version that uses a combine user event case for all buttons and uses the outer loop for everything by modifying the timout as needed.

 

 

 

Message 17 of 24
(2,302 Views)

@altenbach wrote:

@CETGirl wrote:
Here is a VERY simple version of what is going on. As far as how many controls, it depends on the application, some have 10+ others only 4-5. Thanks for all of your help 🙂

Here's a very simple modified version that uses a combine user event case for all buttons and uses the outer loop for everything by modifying the timout as needed.

 

 

 


Don't teach her bad habitsSmiley Wink

 

A well designed PC loop  with the QSM having Init, Take Reading, Delay for next reading, Verify, and Exit states would be much more scaleable...And it needs scaling up according to CETGirl.


"Should be" isn't "Is" -Jay
0 Kudos
Message 18 of 24
(2,294 Views)

(seems this discussion took a turn and I fell off, so consider this an 'aside':  If you need to programatically enable or disable (grayed out) a lot of controls while the FP is visible and running, you should set the 'defer front panel updates' to true, then toggle your control enable states (or update their names/labels if you load the 'description' string from a UI config file for example), then once all updates are done, set 'defer front panel updates' to false.  This way all the updates are synched to the same re-draw and you don't get that blinking and 'one at a time stuff is changing in front of my eyes' thing going on.)

QFang
-------------
CLD LabVIEW 7.1 to 2016
0 Kudos
Message 19 of 24
(2,289 Views)

Could you show me a simple example, I'm not sure I'm understanding how you would structure this...

0 Kudos
Message 20 of 24
(2,235 Views)