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!
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

There are cases where a variant constant / control needs to have a data value. This can be done by right-clicking a control / constant, selecting Data Operations -> Copy Data, then right-clicking the variant and selecting Data Operations -> Paste Data. This can be time consuming for many variants.




The idea is to allow dragging and dropping of a control or constant onto a variant, and have the data copied to the variant:


  • UI & Usability

CTRL+Click on an input is a great little tool to switch the input.


However, it only works when both inputs are wired. Often (, I or QD connected a wire wrong,) I feel like switching the input, before wire-ing the 2nd. Only to find it doesn't work...


Having to connect the 2nd wire just seems to disrupt the flow, being focused on the first input. Being forced to make things worse (connect two wrong wires) before being able to make it right just feels itchy to me.

Switch one wire.png


It's a minor thing, but I never understood why it would be limited to 2 wires.

  • UI & Usability

Panel Actors provide a very extensible UI tool.  There is simply nothing better than panel actors to build composite UIs, but we are still limited in that we can only insert UI elements into existing sub-panels or new windows.  What if there was a simple function called Create with inputs of size and position, and an output of the reference to the created subpanel?  What if closing the subpanel reference removed it from the front panel.  Now we could create an infinitely complex UI at runtime.  It should be a simple matter to build special support for this into the runtime environment. (I actually have no idea how hard it would be)


Use case: an acquisition UI with pre-defined display elements (graphs, gauges, numeric boxes, etc, etc), all created as individual panel actors.  The user asks for a new graph element display during runtime.  We programmatically drop a subpanel and then spawn the requested graph actor into it.  User wants it moved, and we can do that with mouse events.  Same for resize.  User wants it gone and we can do that too.  User wants 10 elements or 10,000.  We can do that with no problem.  Give us this and we can create literally any UI of any complexity, fully configurable by the user. 

  • UI & Usability

When you use Quick Drop to insert a division operation onto a wire: you almost always want the numerator to be automatically wired, and the divisor to be unwired.  Yet, Quick Drop always wires up the denominator.





  • UI & Usability

If there are multiple projects with the same name listed in the Recent Projects list, there's no way to determine which is which:




The idea is to display a tooltip showing the full path of the project when hovering over an entry.

  • UI & Usability

When I print a front panel containing a graph (who ever does that?) I get a stunningly beautiful publication-quality render of my data (overlooking the poorly done vertical y-axis label). However, all the many options of directly exporting a graph image (detailed here) ultimately provide only a screen-resolution image. See the contrast in image quality below:


Comparison.pngPrinted front panel vs exported graph image.

This idea has been discussed ad infinitum on the forum (see, for example, here, here, herehere, and here), but has never been adequately resolved. (Enlarging the graph for export does not work since graph elements do not scale, so lines, points and labels end up being far too small.) High time to implement a feature that has been in demand since (at least) 2002!

  • UI & Usability

One of the most over-looked LabVIEW VI Properties, mentioned in all of the "Good LabVIEW Coding Practices", is the one called "Documentation", where you describe what the VI does, and its Inputs and Outputs (at a minimum).  [NI Examples are certainly guilty of this].


I've been trying (and mostly succeeding) to ensure that every VI I write has such Documentation.  Sometimes I make a mis-type, highlight "bad" parts, and hit the "Delete" (or backspace), then say "Oops, erased too much, let's undo that with ^Z".  Except there is no Undo, or at least it isn't bound to ^Z here.


I can find no other place in LabVIEW that doesn't allow ^Z to replace deleted text.  It works in String Constants, in Labels (whether Free Labels or names for Controls/Indicators), and other places.


To encourage LabVIEW Developers to use the Documentation property, can you please allow us to "undo a boo-boo" with ^Z?


Bob "Imperfect" Schor

  • UI & Usability



  • UI & Usability

The proposal consists in being able to format the content of a string control, to allow to read more easily: INI, XML, HTML, ...


Code Formatter.PNG



  • UI & Usability

Say I have a VI with an arithmetic function: add, subtract, negate, etc...


I would like the ability to programmatically change the output configuration of the function through scripting. Right now (as I understand) you can only read the datatype of the output terminal but not set it. I specifically want to be able to control the fixed-point configuration of the output of these functions through VI Scripting.


[admin edit]: I added an attachment to this post pertaining to the first comment on the thread (since comments cannot contain attachments).

  • UI & Usability

Title basically says it all but I'll elaborate.  With increasing monitor resolution, a 16x16 glyph on a listbox doesn't work very well.  On a 4K monitor this is awful tiny.  This idea is to support larger glyphs in Listboxes, Multi-column Listboxes, and Trees.  Glyphs are used in several places but on favorite of mine is to have item selection with checkboxes, example here.  Allowing for these glyphs to grow with the row height would make them appear more cohesive.  There is a thread discussing this topic, and a work around involving an array of picture rings that is placed over the listbox control.  Here is a demo from that thread:



This work around is fine for simple things but doesn't scale well, and doesn't support trees easily.  I for instance want to have two trees, where a user can drag and drop from one to the other with the larger glyphs coming along with the drop.  Having to handle where the user dropped, and then dynamically building the glyphs to overlay on top of the tree, with indentation, and hiding when a tree's leaf is closed is a major pain.  Please NI add a feature allowing for larger glyphs, and I would be so happy.

  • UI & Usability

I am not happy when I inherit legacy code where VIs have inconsistent alignment grid options, as shown in the image below.Inconsistent Alignment Grids.jpg


My team has coding standards we follow, and those standards include alignment grid options. It is labor-intensive to change alignment grid options on legacy VIs because you have to do it by hand, and clicks quickly add up. I wish I could automate such changes.


I’d like to see a few new properties to expose settings available in the editor, as shown below.Alignment Grid Property Nodes.jpg

These properties need to support both read and write.

  • UI & Usability

Add a new button to the search results dialog called "Set Aside" so I can have multiple search results open at the same time.  Put it near the bottom just below the search results.  When you click it, it changes the title of the window to "Search Results - Set Aside 1".  If you click "Set Aside" again when #1 is open, it will open "Search Results - Set Aside 2" ... and so on.  This way you can have several different search results open simultaneously.  I love the check mark feature in the search results, but it resets every time the search windows is closed or overwritten by a new search.  Thus I lose my place if I want to make sure to check every instance of something but need to search again while looking at one item.

  • UI & Usability

I just ran into a situation today where I had a case structure with approximately 64 frames in it, 48 of which I wanted to remove.


The method of right-click the selector, select "Remove Case" (This step is right beside the "Insert Case" which is frustrating), repeat 48 times while the mouse is wandering all over the screen between the case selector and the menu selection..... cue carpal tunnel problems.


I really wished I could just either use the "delete" and "insert" buttons to mimic the appropriate menu selections


Be able to select multiple cases from the "Rearrange cases" window and select "Delete".

  • UI & Usability

When a 1 Dimensional array of any type is showing only a single element, LabVIEW forces a horizontal scrollbar. I couldn't find any documentation or reasoning behind it. It's really annoying and ruins UI design that Vertical is the normal scrolling direction for just about everything else ever and LV messes that up for some seemingly arbitrary reason.

  • UI & Usability

The error ring is a great and simple tool to define errors, especially when selecting "Custom Error Message" and supplying parameters from outside of the error ring.




The fact that the text search doesn't look inside the error ring makes it hard to find hard-coded error codes. 


Idea: I would love to see the search in LabVIEW also find strings inside error rings. 


PS: This idea (or inspiration for it) comes from Stefan Lemmens.

  • UI & Usability

Pict rings support drag and drop from File Explorer, but only for a single image. Filling a pict ring with more than a few images is a slow and potentially error prone process:


Drag and drop image from File Explorer into pict ring
Right-click pict ring -> Add item after
Drag and drop image from File Explorer into pict ring
Right-click pict ring -> Add item after
Drag and drop image from File Explorer into pict ring


The idea is to allow dragging and dropping multiple images from File Explorer into a pict ring, and have it auto fill with each image as a new item.

  • UI & Usability

I have a set of Icons that I use, saved in the folder \<User Docs>\LabVIEW Documents\Icon Templates\VI\BS Icons.  I've gone through a bit of work to organize this folder, adopting the "Reverse Alphabetic Order" that seems to be the Ordering Principle here (i.e. the Icon "Zebra" is first, "Aardvark" is last).  Yet when I open the Icon Editor after starting LabVIEW, "All Templates" is selected (by default), rather than my BS Icons Library.


One way to "fix" this is to empty (or delete) the two "Frameworks" folders, both of which contain a (differing) Icon called "_blank" (so-named, I bet, to "reverse-sort" first in the list).


This is, I realize, a minor "cosmetic" issue, but creating LabVIEW VI Icons is an important part of LabVIEW Style, so why not make it more User-Friendly?


Bob Schor

  • UI & Usability

Right now the search window results have 3 columns, a check box, a number, and a string containing 4 pieces of info (the vi name, window type, object type and element type).


My idea is to reformat the last column into 4 columns.  The results would be the exact same, however they would be in 4 columns.  Then make the multi-column list box sort-able.  So if I click the list on the top of window type, then all the diagrams would be sorted together and all the panels would be together.


The most useful part of this for me would be sorting by object type.  If I look for something very common and get say 500 hits in my project, sorting by object type would be a big help.  Now I can quickly locate the group of hits for, like, an "EnumConstant", or whatever type of object I'm interested in.  Now I don't have to slowly look though the whole list looking for the object types I'm interested in.

  • UI & Usability

Currently, having one misconnected wire breaks the entire wire tree and pressing ctrl+b wipes out everything. Poof!


In the vast majority of (my) scenarios, a broken wire is due to a small problem isolated to one branch so it does not make sense to drag the entire wire from the source to all valid destinations down with it and break everything in the process.


Here is a simplified example to illustrate the problem (see picture).



In (A) we have mostly good code. If we add a wire as shown, that wire (and VI!) must break of course because such a wire would not make any sense.


However, it does not make sense to also break the good, existing branches of the wire (the cluster in this case), but that is exactly what we get today as shown in (B). If we press ctrl+b at this point, all broken wires will disappear and we would have to start wiring from scratch (or undo, of course Smiley Happy). Even the context help and tip strip is misleading, because it claims that the "source is a cluster ... the sink is long ...", while that is only true for 25% of the sinks in this case!


What we should get instead is shown in part (C). Only the tiny bad wire branch should break, leaving all the good connection untouched. Pressing ctrl+b at this point should only remove the short bad wire.


The entire wire should only be broken in cases where nothing is OK along its entire length, e.g. if there is no source or if it connects to two different data sources, for example.


Summary: Good parts of a wire should remain intact if only some of the branches are bad. Wires that go to a destination compatible with the wire source should not break.


(Similarly, for dangling wires, the red X should be on the broken branch, not on the good source wire as it is today)


Implementation of this idea would significantly help in isolating the location of the problem. Currently, one small mistake will potentially cover the entire diagram with broken wires going in all directions and finding the actual problem is much more difficult than it should be.

  • UI & Usability