LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Displaying only the selected case on the front panel

Solved!
Go to solution

I am writing a biomedical code for a pulse duplicator. At the moment, there are three methods of temperature acquisition, a user input, a signal from the sensor connected to the DAQ and as a picture. I have given users the option to choose which method they want however, on my front panel, I can see temperature selectors for all three methods. Is there a way to only display a control for the method selected by the user? Thank you

0 Kudos
Message 1 of 12
(4,702 Views)
Solution
Accepted by F.N

There are several ways to approach this.  The way I would do it is the "Visible" property node.

 

Message 2 of 12
(4,691 Views)

Thank you very much. Could you please provide some more detail to how this could be implemented? Thank you

0 Kudos
Message 3 of 12
(4,687 Views)

The search box at the top of the forums page can help you with that.

0 Kudos
Message 4 of 12
(4,669 Views)

While RavensFan is correct, here is a place to start:

 

 

Message 5 of 12
(4,637 Views)

Thank you BowenM 

0 Kudos
Message 6 of 12
(4,634 Views)

A better way would be to use a tab control. Create three pages, each with the relevant controls and indicators for the current state. Hide the tabs and switch cases programmatically.

Message 7 of 12
(4,629 Views)

@altenbach wrote:

A better way would be to use a tab control. Create three pages, each with the relevant controls and indicators for the current state. Hide the tabs and switch cases programmatically.


Out of curiosity, how is exactly that "better"?  Is it faster? More effecient? More versatile?

0 Kudos
Message 8 of 12
(4,594 Views)

It would be A LOT easier to manage.  Instead of setting the visible property for every control and indicator, you just set the value of the tab control.

 

So faster programming time, faster executable time, and easier to manage.  Yeah, it really does cover all 3.


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 9 of 12
(4,587 Views)

Hi Bowen,

 

I'd agree with Altenbach's suggested approach, for the following reasons:

 

- Tab controls and indicators are straightforward and easy to work with, they're great for beginners. There are no references to worry about, things like implicit vs. explicit property nodes, error handling, etc.

- A tab control allows you to place the controls in the same area of your front panel without needing to worry about things like performance hits from overlaid invisible controls or z-order.  Debugging why your buttons don't work because there's another invisible button on top of it is a big pain.

- Similar to the second point, you don't have to worry about enabling/disabling the controls when you set them to hidden, rather the tab itself takes care of this for you.

-The tab control itself can be used to determine execution states for case structures elsewhere in the application, rather than needing to maintain a separate operating state handler or something similar that controls the hidden/shown and enabled/disabled controls.

 

I'll definitely say that there are lots of good reasons for hiding or enabling/disabling individual controls- a good use case for that would be when one control is shared between multiple states but shouldn't be available for every state.  I don't think this is something F.N needs at this point, however.

 

-Edit- Interesting, it looks like controls with the Visible property set to False can actually be clicked through, you learn something new every day!  Scratch that as a need, then!

 

Best Regards,

Tom L.
0 Kudos
Message 10 of 12
(4,583 Views)