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

When I try to select a word or more words I currently have two options. The first one is to hold down shift and select on letter by letter basis which is slow. The second one is to select with help of mouse, which is error prone.


Normally all text editors have options to move for 1 word left or right by ctrl + left arrow or ctrl + right arrow. The same goes for selecting a word (ctrl + shift + arrow). I would like this functionality to be supported by LabVIEW at least on block diagram, VI documentation, enum editing.

When indexing a map on a for loop, the indexing is automatically done by ascending order on the key value.

I like this as a default behavior.


Capture d’écran 2020-10-06 103344.png

I'd like to have a context menu option to force the for loop indexation to be done in reverse order.

This is related to the Array to Cluster function which has a idea here as well:


This defaults to nine (9) ( but to the new user this may get missed.  I suggest a set size dialog box to pop up when it is first placed on the block diagram.

Via this link, I learned, "If automatic tool selection is disabled, you can use the Wiring tool to select the control or indicator first and then select the terminal."


I happen to like using the automatic tool selection, so can this be an option when automatic tool selection is enabled?



E.g. if one (and only one) control/indicator is selected, clicking on a connector pane terminal will connect the control/indicator.


(I can't count the number of times I've *tried* to do this, even though it didn't work.)


we correctly recommended that the SSS be removed from the Structures Palette.   Let's go one step further.   Default Block Diagram Cleanup to apply the existing "Replace SSS with FSS."

At the moment, if I want to review my search results, I'm required to double click each item. This opens the diagram (usually) and the front panel. I then have to close them, or I might end up with dozens of open windows.


Of course I could use CTRL+G, but I'd still need to clean up the opened windows.


Another slowdown is that the highlighted item can popup anywhere on my screen(s). This "gaze time" adds up if you need to browse through dozens of results.

It would save me tons of time if the search results window had a preview of the result:

Search Results Preview.png

The found item should be in the center, preferably highlighted in some way.


It would allow me to give the listbox key focus, and use up\down to browse through all items very quickly, without any need to clean up!

Some additional thoughts:



 I'd be OK with an image, it doesn't need to be like the DD preview in LV2020. I'd prefer to see an image even if the diagram is already opened...


Scrollbars might be nice?


The proposed image is just a quick sketch. It would need a splitter bar, and perhaps the preview should be optional?


Almost every widely-used software framework, ecosystem, IDE, ... has a public bug-tracking dashboard where bugs can be:

  • reported
  • monitored
  • voted
  • ...

Jira or Mantis are quite common solution.

As a NI user, the current situation it's really frustrating: even for bugs originally reported by me, the ticket is created by a NI engineer.

And so I don't know what information it contains, its priority, if someone is working on it, if it has been already solved, ...


Many years ago NI was a pioneer with the community, but now is ages behind everyone else.

Given the properties dialog box isn't resizable, and there's nothing under the table (apart from one tick box), could you make the items table longer? It's really annoying when there are a few extra values that can't be seen because the table is too small.


Proposal to make the Edit Items box longerProposal to make the Edit Items box longer


FIR Filter is almost the same as convolution, except that it has a init/cont terminal while convolution has an input for algorithm (Direct, frequency domain). FIR filter always uses direct convolution.


If "cont" is not used, convolution based FIR filtering could be orders of magnitude faster because it scales much less steeply with input sizes. Examples have been discussed where switching algorithms from "Direct" to "frequency domain" can turn minutes into seconds (e.g. 1M points and 5k filter).


While the knowledgeable programmer can of course make his own using the convolution primitives (also programming around other limitations because this idea is not implemented :(), it might be more intuitive if the FIR Filter had an "algorithm" input where we can select between the same choices as for convolution. (From my casual understanding, "frequency domain" would ignore the "cont" input because it is incompatible. This can just be mentioned in the help.)




Working with class method VIs becomes easily confusing if you need to use VIs from several classes that are inherited from each other. Every class adds or overwrites VIs from one of the ancestor classes but usually you don't know which one. And if you're just user and not developer of this class structure you're usually also not interested in the exact inheritance hierarchy.


Look at the picture: As programmer of the application "" I'm just interested in Class 3 but I also need to know the internals of Class 1 and Class 2 whereby Class 1 is not even in my project. So I can't see that there are also other cool methods within Class 1 and to get methods from Class 2 I also have to search inside of it and compare against Class 3.




As reference: This is the content of Class 1




What I suggest and expect is the following:


=> The class tree shows all available methods within each single class!

bright colors: Methods that are defined in this class; pale colors: inherited methods



Similar to Visible items>Radix right-click menu it would be highly beneficial to have the same possibility for showing (and switching) of Representation.




Please address the problems/shortcomings when setting file security permissions in Windows File I/O. The current Get Permissions and Set Permissions File I/O vis do not work.


Currently when LabVIEW creates a file it assigns the default security permissions, which are inherited from the parent directory. This is a pain as the current user is allowed, in general, read and write access, but other users are potentially only granted read access. For example, creating files in the public application data directory (as the sample projects demonstrate for storing settings) means that only the user who first created the settings file can update its contents, whilst other users will get a file permission error.


At minimum, I would like to be able to specify what kind of access other users should have when creating a file. Better still, I would like to be able to get and set security info. Currently I am forced to call functions in advapi32.dll to set acceptable permissions (e.g. GetNamedSecurityInfoA).


I am not the first person to encounter this limitation (see, for example,

If you have a missing VI, you can select "replace with" and you'll be brought to a file dialog so you can point the IDE to the file.


I'd like the same functionality with regular files. Currently the "Replace with..." menu option doesn't appear

No Replace.png


Check out this nice readable diagram:


Whoa there pardner, not so fast. The control reference labeled "Numeric 1" is actually linked to the "Numeric 3" control. And the property node labeled "Numeric 2" is actually linked to the "Numeric 1" control. Etc., etc.


I see no reason to change the labels of Control References and Implicit Property/Invoke Nodes. If you need to document them beyond their label, attach a free label to them. We don't allow changing the labels of subVIs, so the precedent has been set. For the sake of diagram readability, we shouldn't allow changing labels of these objects either. 

When you mass compiled, all VIs in the directory tree get recompiled. When you hold CTRL and SHIFT and click the run button on a VI, it forces a recompile of all VIs in the call chain. 


However, when you CTRL-SHIFT-Run, all you SEE is a busy mouse; it would be really nice if you could get a popup windows (the same as when you mass compile) showing what's going on, and giving options to cancel... it would also be nice to be able to specify a log file and how many VIs to cache, same as with mass compile...


It could be the same popup with a different title...



There is a path type selector (Valid Path/Not a Path) on all the path controls. This is useful on "data" type controls (subVIs) where you may wish to test input values, but rarely useful (may even be confusing) on path controls used on end-user facing front panels. They make no sense at all on indicators. These selectors are most prominent on the NXG style controls:


NXG Style Path.png


Here's an idea to be able to hide these buttons, just like we can hide the browse button. Perhaps Show/Hide/Hide at runtime options, but at least Show/Hide options.


in many cases after wiring in the loop , we will go for the shift register to store variable. but in case of changing the loop tunnel to shift register left side tunnel required to connect manually.if not it creates the another tunnel in the loop.



in the loop , if the left and right tunnel variable are same , LabVIEW automatically replace tunnels with the shift registers.


shift registers.JPG



This one's pretty simple...  Multicolumn listboxes have a "Moveable Column Seperators" property that's available from the menu at edit time:


But this property isn't exposed through property nodes.  I'm currently in a situation where I really wish it was!


I'm not the only one who's encountered this:

I have been pretty slow to pick up the addition of quick drop functionality. This is mainly due to the list of shortcuts being out of the way.


I have always thought it would be easier to get the hang of Quick Drop if I had the option to put the quick drop shortcut in parenthesis next to the object name in the function pallet.  That way when I go back through the "normal" way of programming I will see the shortcut each time and over time I could get the hang of each objects shortcut. 

I often create maps in a for loop, as shown below.  However, the "Insert Into Map" value input doesn't adapt to the value type, leading to extra hurdles in order to create the correct map constant to feed into the for loop/VI.



It'd be cool if I didn't have to do the extra work to create this map constant.  Ideally I'd be able to wire any value type into the "Insert into Map" VI, and then just right-click on the output terminal and select "create constant".


(It appears that you can now drag and drop a value type into a map constant which does make it easier, previously I would "build map" node in, get the constant it from it, and then delete it. Either way, it's still extra steps.)