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

Incorporate NI Batch Installer Builder into the general application builder suite.


This tool has a lot of potential for end-user use if it is incorporated into the app builder API and suite.  Batch installers can be used for much more than just installing selected sets of NI software (Which this tool is obviously designed specifically to do).  It could be used for creating installers of multiple, cross-project user installers comprising a complete system.  To do this though, the current batch installer builder needs to be made more generic to be of use.




  • Add configuration options to control or disable license dialogs when non-NI provided installers are added
  • Add configuration options to control or disable the user/company license dialogs when non-NI provided installers are added
  • Add configuration options to control or disable the check for NI updates dialogs when non-NI provided installers are added
  • Add batch installer version properties to allow end users to create system versions
  • Add support for 3rd party installer inclusion (Dup from another idea, but I had to repeat it here)

Including this in the app builder would be even better since that should allow project based configuration and control of the batch configurations and potentially even programmatic control.

This idea is to improve the QuickDrop search window, to return functions that might be betters suited, based on the datatype of the selected function or wire.  Lets say I have a 1D array of numerics selected and I want to reverse it.  I will select the wire, then invoke QD and type "reverse".  But the first item in the list is actually "Reverse String".  With a context aware QD hopefully the search window will see I have an array of numerics, and prioritize the Reverse 1D Array function, and still include the reverse string but maybe push it farther down the list.  


This idea can be applied to the basic data types pretty easily (numerics, boolean, array, string, cluster).  But we could also use this on class wires that are selected.  A class library can have an associated mnu file, which is why some functions you can right click and the corresponding subpalette menu comes up.  So this idea could also prioritize functions that are found in the mnu associated with the class.

0 Kudos

It is currently difficult to select all the contents of a cluster without selecting the cluster itself, on the front panel or a block diagram.  This is especially true if the contents are themselves clusters or arrays; a marquee selection often picks just a few elements from them.  I suggest having a command on a cluster's right-click menu called "Select all cluster contents" that does exactly that.  Alternatively, or in addition, this could be a shortcut such as Ctrl+Shift+A (to match the existing Ctrl+A for selecting everything on a front panel or block diagram).


An example situation where this is useful is when you place a TypeDef constant on the block diagram, and want to show the labels on each element of the cluster, to help you fill in the values.

Overlay drawings are super useful for highlighting regions of images, but sometimes just a solid line is not enough. I'd like to be able to change overlay line types between Solid and a dashed or dotted line. Color isn't always enough to discern between different overlays and I think line styles would help with that. I've considered how to do it myself, but it seems like it would probably take much longer to compute segmented overlays than something built-in. 

My idea is very simple - I'd like to see new size(s) indicator available for arrays, so user may know which dimensions his/her array has. The necessity partially arises from this thread. In that case the array looks visually empty but really contains some hidden row or column and there's no way to know about it except for calling Array Size instrument on it. Also it would be good for the developer to see the exact number of elements in the array on FP or BD.

I suggest this new context menu item:

Size(s) menu item

The indicator might look like a common LV indicator like this one:

Size(s) indicator


I know that its implementation adds one additional operation in IDE mode but I think it should be fast enough to work smoothly.


Working with applications with 5000+ VIs means a lot of folders, libraries and classes. Normally you work on a specific class for a while, or perhaps a method of that class. But every time I have to restart LabVIEW for some reason I have to do a lot of clicking to get to a specific VI. If I'm lucky it is in the Recent Files list, but many times I'm working on more VIs than the list contains and have to click same path down in the project, over and over again.


Wouldn't it be sweet if you could right-click on a VI/class/lvlib/control and select "Create shortcut" and a link to the item in the tree is created in the "Shortcut" folder? Right-click on a shortcut and select "Remove shortcut" and it's gone.


I also have VIs in my project that I use often (for example a GUI showing all modified VIs in the project, where I can mark VIs and lock them in Subversion) and they would always "hang out" in the Shortcut list. So perhaps it should be possible to mark items in the shortcut list that are permanent and follows you in all projects.


0 Kudos

LabVIEW 2017 ships with an example project, Channel Message Handler.lvproj, which provides a starting point for a QMH using channel wires. However, it would be neat to have a more sophisticated sample project (something on par with the Continuous Measurement and Logging sample project) which uses channel wires as opposed to the traditional queue approach.



Many programs use shift+mouse wheel to scroll left and right, I would love to see labview enable this for in the block diagram edit window.

0 Kudos

Unbelievably NI has introduced a bug into LV 2016 whereas the "Open/Create/Replace File" function does not display the input prompt to the user.  In fact no File I/O functions will display the inputed prompt.  Worse yet there are no prompts for finding or opening files within LabView itself.  Try opening a vi, there is no prompt whatsoever.  In previous versions of LabView there is a prompt telling the user what to do.  e.g. "Select File to Open"


This is very bothersome when you open a vi that cannot find a called vi.  Prior to 2016 there would be a prompt telling the user what vi it is looking for.  Now you are left to guess what vi Labview cannot find.


This is a huge problem for me as I prompt the user to find files and folders in a  great deal of my code.  If I were to upgrade to 2016 I would have to go through 100's of vi's and add dialogs telling the user what to do prior to calling any File I/O functions.


The most disturbing aspect of this issue is that NI did not fix this bug prior to releasing 2017.  It is beyond me how this bug could have made it to another version.  This bug alone requires a fix and an upgrade for both 2016 and 2017 immediately.

I propose that if an array is wired into a for loop, the tunnel should be auto-indexing by default (current behavior) UNLESS there is already an auto-indexing input tunnel in that for loop (new behavior).


Generally, when I wire an array into a for loop, I want an auto-indexing tunnel, so I am happy that it creates one by default. However, when I wire a second array into the same for loop and it creates another auto-indexing tunnel by default. This is usually not what I want because it will cause the loop to stop early due to one array being smaller. I'm afraid that this default behavior may cause bugs for new programmers because they may not realize to change it (in fact, this has even happened to me before). Default behavior should be the "safe" behavior. Making the decision to have more than one auto-indexing input tunnel in a loop is one that should be carefully considered, so it shouldn't happen by default, but rather should be changed explicitly by the user.


I know there have been many ideas posted about the current auto-indexing default behavior, but I didn't see this specific one anywhere, and I think it is an important suggestion.

0 Kudos


Simply put, click and hold middle mouse should use the pan tool, as opposed to duplicating left click functionality. This should be trivially easy to implement, as opposed to the universally desired zoom function.


User-configurable input mapping would be nice in general. 

Now that the SSP package is delivered on USB instead of DVDs (good stuff!), I have a minor request: Could you have the USB label include a release/version name on its label?

It might add too much of a cost depending on how you get them customized, but if that is not an issue it would be very practical to be able to see what the USB contains by its label (as we could with the DVDs).Smiley Happy


On a side note: Many companies have strict regulations on the use of USBs, and the need for such has increased with weaknesses like BadUSB. Perhaps NI could state something about how the USB sticks they send out are protected, either in the delivery package, or just as a statement on That way people who need to convince their IT departments to allow them to use the NI USB sticks will have something to show (I'm sure you will have to add some legal disclaimers there as well , but that's OK).

Many controls allow you to make scrollbars visible. When a user clicks anywhere within the control, including on the scrollbar, this counts as a Mouse Down. It would be nice if the Mouse Down event would indicate whether the click was on the scrollbar or on the actual clickable area of the control, so you could do different actions based on which it was. Of course, you can usually do manually by checking boundaries of the control against the coordinates of the click, but it seems like a common thing so it would be easier if the check was built in.

Scrollbar Idea.png

0 Kudos

I have made a printout VI to show variable names and values. But values will not get proper names until it reach destination. One solution I am using is typecasting (see alternative 2). But typecasting is dangerous. If data in is not of same type as data out, it might be converted to rubbish without warning.


Dear LabVIEW team, could you please give us a function to convert data names in wires? 


Debugging would also be easier if content of wires had proper names.


Idea exchange.png

There is no way how to programatically disable the Run-Time Shortcut Menu with a property node.

The only way is to work with event structures what is quite unhandy:

The ctrl+drag and ctrl+alt+drag shortcuts for adding and removing space on the BD are super awesome. But I think they would be even *more* awesome with the following tweak:

Limit space addition/removal to the visible diagram; i.e. don't make any changes to other cases in a case structure.


I have had many situations where I was doing cosmetic tweaks in one case of a case structure, only to find I have overlapping items in another case that I wasn't looking at.




Hopefully this simple animated gif demonstrates what I'm talking about.


(And yes, I know we could enable "auto-grow" on the case structure to eliminate the shrink-case-smaller-than-contents problem, but that still doesn't address all the potential issues here.)

0 Kudos

I was thinking that it would be nice if there was a default connection of a pass-through register.  Similar to the shift register only here it would pass the input to the output by default rather than having to wire each case.  If there is a wire into the output, the default connection is NOT selected.  In the snippet, both the top and the bottom outputs are the same for this case.  It would make for cleaner looking block diagrams if the only thing happening in a particular case is the wiring of an input to an output.Pass-thru Register.png

0 Kudos

1. An extra input for casting to a more specific type:

Instead of this: ep1.png have this:ep2.png


2. Allow property & invoke nodes to auto close a reference (right-click the node, select auto-close on/off):

Instead of this:ep3.png have this:ep4.png

0 Kudos

From time to time it would be handy to have an "insert again" option on the context-sensitive menu; not necessarily a history for insert (as suggested at where the poster does mention a single-item history) nor as extensive as QuickDrop - just a simple repeat of the last inserted item.  Here is an example of being able to insert another conversion identical to the one just inserted, with a minimum of mousing and no keystrokes.




One (probably superior) alternative would be to change the behavior of <ctrl><right-click>; hovering over a wire and pressing <ctrl> shows the wiring tool, and a right click could repeat the last insertion (instead of bringing up the context-sensitive menu, which is a redundant behavior and a squandered control sequence).

I like constant folding.  LabVIEW says "this is going to be a constant".


There are some times that I want to see the actual values of the constant.  In the middle of a large VI it can be a pain to de-rail to make a constant, then come back.  It can be easier to look at an array of values for troubleshooting.


I wish there was a way to right-click and either show what constant-folding gives, or even convert it to an actual constant.  This is going to change the development side, not the execution side.


While it doesn't have to be reversible, it would be nice to know I got it right, then revert it to code, in case I want to vary the generation of values at a future time.