LabVIEW Idea Exchange

Community Browser
About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
Showing results for 
Search instead for 
Did you mean: 

Do you have an idea for LabVIEW NXG?

Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!

Post an idea

None of the inputs to the Format Value function are required. The Format and Value inputs should be required, because without both of those the function is pointless.

Everytime I build an executable I have to provide a custom INI file just to disable the localized decimal point. Please add a checkbox for this important setting to the application builder, e.g. on the "Advanced" page.

For non-integer increments, the data entry currently accumulates binary errrors due to the limits if the DBL representation, so e.g. sometimes the upper limit cannot  be reached using the increment button several times, but only when entering the upper limit directly.


This comes up at regular intervals, e.g. here. In one fo these discussions, I long ago suggested to make it into an idea. It seems this has not happened, so here it is! Smiley Happy


This limitation needs to be handled with some internal code, e.g. to coerce the value to the nearest decimal fraction based on the least significant digit of the increment value whenever the up/down buttons are used. ... or something similar. Smiley Wink

FP Free Label.PNG


This one may have been overlooked before.  Often experienced users will enable FP gridlines to help with object placement.


Tools>>Options--Front Panel Grid section offers some very useful usability enhancements.  But, when you move away from the default settings you miss one thing.  The Gridlines are the same color as default text and free labels become difficult to read.


Now go check out the Block Diagram section 


I have an option to use Transparent free labels.  Which, of course, I use even though it is NOT the default because I use wire labels and transparency is desired to avoid hiding wires!


Going one step further and thinking about it, why would transparent free labels be the default for FP but not BD? and why can I only change the behavior for the Block Diagram and not for the Front Panel?


Looking at the first picture again.  Is the 1 pixel border really needed?  a "Non transparent" free label does not need a border.

I want to be able to add documentation to the controls and indicators that are Classes/Objects like I can to every other control/indicator.

For the most part coersions can be broken down into two classes: lossy (e.g. 64L to I8) and safe (e.g. U8 to U16). Why is there only one color option for coersion dots?  Could the vi analizer have seperate settings for max allowable safe and unsafe  coersions?

The loop stop function now accepts errors directly which is an improvement but there are many cases where loops must stop based on multiple sources.


If the stop function had several inputs (eg 4 - one one each side), this would allow multiple errors or stop commands all OR'd internally within the stop function to work without the clumsy OR function that is so commonly used.


There is no reason the OR couldn't be built into it and make everyone's live's easier. It would also simplify coding and increase speed of development.

Currently, when opening a command window with the System Exec function, the "wait until completion?" option performs two operations.  It causes the VI to wait until the command is completed, and it suppresses the output in the command window.  The output becomes available on the standard output terminal after the command has completed.  This causes problems if you need to see what is happening in the command window, and you need the VI to wait until the command has completed. 


It would add more functionality if these options were separate.  One option, "suppress output?", would suppress the output in the command window and put the output on the standard output terminal.  The second option, "wait until completion?", would make the VI wait until the command has completed.

When setting the option "Separate compiled code from source file" will make the .vi-file NOT to contain executable code.

The forum filter accepts .vi files to attach to posts. But if selecting VIs with this option set, the posting is declined with the remark that the file type is invalid.


I recommend updating the attachment filter to accept VI files with compiled code removed.



I would like a better way to clear the list of recent files and recent projects in LabView.  It is often disireable to clear the history when changing to a different project or a different user.   Currently the user must close LV, edit the .ini file and restart LV.  I would like to see menu selections added to allow the list of recent files and/or recent projects to be cleared.

I use a lot of clusters in some apps and using the in place element box can make the diagrams significantly larger and a bit unwieldy if you need to do some complex calculations. My idea is this:

step 1.jpg

right click on the increment icon:

step 3.JPG

Click on "Inline":

step 4.JPG

The box indicates that it is an inline operation so we also don't need to define the receiving cluster as labview knows that it is the same as the source cluster. The receiving cluster can now be placed where it is most convenient rather than being tied to the in place element box.

I like LabVIEW to add “Unload All Modules” menu item that will unload any library that User has loaded during the LabVIEW development session.
The Modules can be LVOOP, dll, .net dll, ect.



Right now, we can only edit a few select build specification properties, such as Icon, Name, and DisplayName. I think it would be very useful to be able to edit more of these properties programmatically.


Things I would like to be able to set/read via property nodes:

Build specification name

Target filename

Destination directory

Build specification description

everything under "Version Information"


Other items would be useful as well, but those are the ones I care about the most.


It would be a very nice addition (especially when using XControls) to be able to actually programatically activate a right-click menu for a given control.


As it stands, one of the rather annoying disadvantages of an XControl is the inability to directly configure controls visible ont he Facade VI on a per-instance basis.  The ability to programatically detect right-clicks and activate the appropriate right-click menu would be cool.


It would also allow for UI features like a google map delayed right-click menu appearance.  If we double-click the right mouse button, zoom, otherwise (if a single click within a defined time period) open the right-click menu.

After installation we might have to set the ProgramData rights.


I can run an executable, but it has to be in the installer, and therefore in the project. Why? I just want to call:


icacls "%USERPROFILE%\DSS Measurement System\*" /grant UsersSmiley SadOI)(CI)F


Now I have to work around it. Perhaps create and include a batch file that deletes itself?

Without Event Stop.jpg


I've done this like a milion times! It's not very "pure", but how convenient would it be if the event structure itself kept looping until stopped?

With Event Stop.jpg

This should be optional, like in the for loop ("Conditional Terminal").  For the event stucture, it wwhould be nice if wiring it is optional (unwired means keep looping), or that you can show\hide it on a per event basis.






Many people don't know, but there is a great VI in vi.lib called Open a Document on which does exactly as it explains.  If you feed it the location of any document (Word, Excel, HTML, PDF, ANYTHING!) it will open it with its default program on the computer.  Unfortunately this VI is hidden from the palette deep inside the vi.lib somewhere.  I think this should be placed on the palette as it can be very helpful in application development.


The VI is located at C:\Program Files\National Instruments\LabVIEW 2009\vi.lib\Platform\browser.llb\Open a Document on (default LabVIEW installation directory may be different) 

Wish there was an “inspection window” showing the block diagram of a sub-vi on mouse-over. (double-click & open to edit). Perhaps, it can even appear below context help.


(Not sure if someone has already suggested it) 

Ever right-click a VI, reference, property node etc and have the search window pop up showing it is in multiple places. Then you double-click one of them or press go to and the window closes, only for you to realize that you didn't click the instance you were looking for?! So, now you have to go through the whole process again. Not to mention you don't know which one you just clicked on so you don't know how to pick up where you left off. Disaster. Please, just have the window stay open and your recent selection stay highlighted after going to that instance!



I don't like that controls, type defs and strict type defs all have the same file extension: "*.ctl".  I'd like to see something like:


  • Standard control: *.lvctl
  • Type definition: *.lvtypedef

(I don't think there needs to be two extenstions to distinguish between type defs and strict type defs).