Example Code

Simple Utility for Showing or Hiding VI Front Panels with LabVIEW

Products and Environment

This section reflects the products and operating system used to create the example.

To download NI software, including the products shown below, visit ni.com/downloads.

    Software

  • LabVIEW

Code and Documents

Attachment

Overview

This simple utility shows or hides a front panel whenever I launch a subVI dialog. There are two VIs of interest: Show VI.vi and Hide VI.vi.

 

Description

I've been posting a lot of XControls to this forum, so I thought I'd take a step back and post some simple code that users can use without having LabVIEW 8!I use this simple utility all the time to show or hide a front panel whenever I launch a subVI dialog. There are two VIs of interest: Show VI.vi and Hide VI.vi. Just drop them into a VI to show or hide it respectively.Pretty easy to use. The subVIs only have error in and error out terminals. They come with a small example two of how to implement them. Change control: Merged Show VI.vi and Hide VI.vi into one VI that uses an enum to set the Front Panel state to whatever the user chooses (Hidden, Standard, Minimized, etc). The original Show VI and Hide VIs are still in the llb. The new VI is called Set FP State.vi.

 

Requirements

Software

LabVIEW 2012  (or compatible)

 

 Steps to Implement or Execute Code

Just drop them into a VI to show or hide it respectively.

 

Additional Information or References
Block Diagram

 

 image.png

 **This document has been updated to meet the current required format for the NI Code Exchange.**

Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.

Comments
BetaCommunityCo
Member
Member
on

Improvment Idea

It might be better to have one VI where the user can wire in an enum to set the visible state (this will allow more than just hidden and standard) - maybe even add an enum item to return the FP to its' previous state...

BetaCommunityCo
Member
Member
on

Re: Improvement Idea

I agree with this idea. I think originally I wanted the code to be as small as possible on the BD. But I implemented your idea for maximum flexibility. Having a return to previous enum would require keeping track of which VIs were in what state, since this non-reentrant subVI could be called from multiple locations. This adds unnecessary (if convenient) overhead to the program.