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: 
Post an idea

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



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.

The QControl Toolkit is a fantastic library of tools for developing reusable UI components. I think they are a great alternative to XControls. Not only does the QControl Toolkit provide me the framework for developing my own QControls, but it also ships with some fully functional QControls, my favorite probably being the tree with checkboxes.


I think QControls are useful enough for all LabVIEW users that they should be part of the LabVIEW core product instead of an add-on toolkit.

If I am on Mac or Linux and I try to open a VI that calls a DLL inside of a Disabled Structure, then LabVIEW searches for the missing DLL.


This is really a waste of time and effort, since it will never find or be able to load the DLL on Mac.


LabVEIW should be smart enough to know that it's not going to file a *.dll (Windows dynamic linked library) or a *.so (Linux shared object) on a Mac -- Mac uses .framework as it's shared library files.


So, I would extend this a little further and say that LabVIEW should only search for shared libraries of the type for that platform (.framework on Mac, .dll on Windows, .so on Linux).


Note: if a Call Library Function is configured for cross-platform (meaning it's configured for with a "*" file extension like mylibrary.* so that it will find the correct extension on the target platform) then go ahead and search for it.






In some cases the list of context menu items extends beyond the vertical screen height (for example when creating a property for a control). The only way to scroll up or down this list using the mouse is by hovering over the small arrows at the top and bottom (and quickly moving the mouse away to stop scrolling).




This idea is to enable mouse wheel scrolling on context menus where the list of items is scrollable (the scroll arrows are visible) and the mouse pointer is hovering over the list. This allows for precise scrolling with much fewer mouse movements.

When creating a new Source Distribution to run on an RT system.  It makes no sense that the "Exclude vi.lib VIs" option is checked by default.  The VI will not run and cannot be launched asynchronously which is the whole point of a source distribution on an RT system.


The "New Source Distribution" wizard that creates it with default properties should look at the context it is being created and pick appropriate options.  This is supposed to be a smart IDE.

When I Control+Right click and drag to expand a block diagram. The expansion should NOT effect all of the unseen case frames


I am really tired of stuff like this happening when I expand the diagram of another frame of the same case horizontally and vertically.


This "Short cut" actually creates a lot more work for me as now I have to go back and clean up all the other states in my state machine that are messy now.




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.

When working in LabVIEW in low light conditions, it would be nice to be able to have a quick way to switch to a dark mode, where the default block diagram colour would be a mid-dark-grey.

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.

When I'm explicitly defining an empty string as the value of an output tunnel, I prefer the empty string constant for instant readability.

It would be useful to be able to create one from the context menu instead of using quick drop or the palette.


If you vote for or like my idea, please vote for Jim Kring's idea first, because the implementation of his idea would eliminate the need for this one. (Yes, shameless plug on my part)



The idea is the same as Separate Compiled Code From Source File. When using external source code control (SCC) software like git, the user may want to track only the source code content changes. However, when every time saving the VI, the VI Revision History will be incremented. This reflects the change in VI attribute / VI properties, even though the other contents are the same.



This makes the commit log like git hard to trace the real change in the source code content from a high level. When using the compare VI tool, this attribute change will be one of the highlighted difference, which is quite distracting & confusing such as below:



I suggest this option can be disabled at the level of VI, project, or environment like the option of Seperate Compiled Code from VI. Hope it would be accepted 🙂

It can happen that a VI, or worse a typedef, gets inadvertently pulled into code from another library or class simply to reuse code.

Using "Why is this item in the Dependencies" isn't particularly helpful in a large project.


Could not the offending dependency be marked with hot pink or similar to using a breakpoint? Could the Breakpoint Manager be adapted to finding dependencies?

LabVIEW currently allows users to execute a MATLAB script inside the "MATLAB Script" structure, which lets you add inputs/outputs to the edge, set datatypes, and then type your MATLAB code in the central box.


If you already have a MATLAB script, you can use the right-click menu to "Import" (and conversely, you can test a script in LabVIEW and then Export it, if you wanted).


However, you cannot link to a script by path. Importing simply copy-pastes the content into the Script node. This behaviour, whilst probably useful in some cases (avoid future changes to the .m file breaking your nicely tested LabVIEW code) is different to most other nodes I can think of (Call Library Function Node, Python Node, .NET methods, ...).


Please add an option to pass a path to a "myFunction.m" file to the MATLAB execution system rather than copying the contents of a .m file into the structure's box.

(As a workaround, I believe this could be accomplished by running the MATLAB interpreter via command line and using the System Exec node, but that would require various path -> command line string parsing operations, and perhaps complicate cleanup of VIs using MATLAB.)

I know that many extract wires 'upwards' and later on merge errors to collect errors and continue. From a layout perspective it's natural to add the top code to the top input of Merge Errors, but from a data flow perspective any error that happens there is often secondary to the 'base/lower' part of the code. This means you need to connect the top code to the bottom input of Merge Errors.

Wouldn't it be nifty if you could have an r-click option or input of "reverse order" or "merge from bottom"?

I assume that it behinds the scenes makes an array of errors and looks for the 1st one, so this would only add a 'reverse array' inside the function. To not have that ability forces you to do a Build array, Reverse array and Merge Error, which feels unnecessary.

I would be easier if Save all the logs to file option is provided. 

Proposed Event Inspector WindowProposed Event Inspector Window

Actual Event Inspector WindowActual Event Inspector Window


For all of the work the knights of the forum do, I propose that upon retirement they receive a lifetime license to LabVIEW.

  1. They deserve it.
  2. Their help on the forums for other users cannot be quantified. 

Not sure where I read it on the forums, but I think it stinks that @Ben needs to wait until the community edition is released to have a working copy of LabVIEW.



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


Since development of Labview NXG will be discontinued this year, a back conversion tool would be extremely helpful in order to move NXG-projects back to the original Labview. I think NI has the responsibility to help the programmers who followed their call to the "new and future version of Labview" which is now discontinued.