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

If I have a Control labelled '%s In', I would like to be able to right click on it and select Create Indicator, resulting in a terminal label of '%s Out'. Likewise, if I have an Indicator labelled '% Out', I would like to select Create Control and automatically label it '%s In'.




Simple enough, but one of those tiny little tweaks that would save me a tiny fraction of effort every time I do it 🙂

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?


When LabVIEW displays text, you are allowed to choose the following types of justification:  LEFT, RIGHT, CENTER.


Wouldn't it be much prettier if we could also select "fill justification".  Below is a subtle example, but its known to be easier on the eyes. 

Upvote!  😁






Problem Statement

Sometimes, you may want to delete files that are read-only. The Delete primitive outputs an error (Error 😎 when you try to delete a File that's set to read-only. One then has to change the file permissions to writable and retry deleting it. That's a pain. What's even more painful is when you try to delete a folder, recursively, with the Delete function -- passing it a folder path and setting Recursive to TRUE.  In this case, if even a single file inside the folder is set to read-only, then the recursive delete will fail -- now, the developer has to do their own recursion to find the file that's read-only, mark it as writeable and then delete it. OK, convinced this is a pain?  Here's the solution...




Proposed Solution

Add an input called "Ignore Read-Only" to the "Delete" function that will do all this form me.



The OpenG Delete Recursive VI (in the OpenG File Library) has such a feature already. I was excited when LabVIEW implemented a recursive delete and I started using it all over the place (it's nice to write code that doesn't depend on external libraries, when possible) and then... I got bit by this limitation in some random corner cases where files had gotten marked as read-only.





Breakpoints are great for debugging.  But...I've never wanted to share them with another developer, and I've never liked it when they add the dirty dot to code that I haven't otherwise changed.  This can lead to unnecessary code changes which can add hassle to source control, and it can lead to other developers unintentionally inheriting your debugging breakpoints.


How about an option to manage breakpoints separately from source code, perhaps similar to how compiled code is handled?

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.

Sometimes, it can be useful to know the last event handled by an event structure.




This idea was posted years ago and declined for lack of interest  (it got 6 out of 7 necessary, but I would have been the 7th!).  I would like to bring it back, I would like my application to have access to it's own version number.  In fact you can open the project programatically and see some build properties but not that one.  I can then grab the version from the build properties and set the default values on my FPGA code before compiling.


I was trying to make a pre-build VI that would look at the build properties and copy the version data into a control.  Can't be done.  I find this very useful to make sure that my RT system and my FPGA code have the correct versions.


Same as with an about box, or version checking for compatibility.


The previous thread suggested a routine in the FileVersion.llb but that seems to only be available in a single platform.  Not useful for RT linux or Mac.  The version is not available until the executable is built which does not work for FPGA.


At the moment my only recourse is to hand copy the version from the build properties and then set those as a series of 4 integers on the FP.  (Then select them all and set their values to default, hence the other suggestion about right click)

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)



Since LabVIEW 2017, the default build specification check the option "Allow future versions of the LabVIEW Runtime to run this application".


I don't undertstand why it is checked by default when you read the help that said "Disabling this option prevents any changes to the performance profiles and helps you avoid unexpected problems resulting from compiler upgrades."


Because NI and me doesn't know the future, NI will never garanty that your application will run with all the future LV Runtime. I know it well because I'm facing this issue with le LV RT 2020 that breaks the execution of different application that I have buid in 2017 SP1.


The behavior is a little strange too, because, even if you have the run-time use to build the application on your computer, the application will use the highest one present one the computer.


This options can be very usefull, and I appreciate it, but maybe we need to have more control on it. So my idea is to give to the user the ability to list supported or unsupported LabVIEW Runtime.


This will help us managing future LV Runtime without having to recompile the application which seems to be the goal of this option.


for Example :



ExcludeLVRTe = "2020,2021"



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


There's a lot you can do with LabVIEW to improve the appearance of the UI.  The community has really helped move the LabVIEW UI frontier forward with many wonderful UI palettes and tools to improve UI creation and customization.  One key limitation to all of this though is that LabVIEW controls are comprised of parts that are NOT programmatically accessible.


This is a large drawback since it prevents developers from creating dynamic UIs.  For example, you cannot really add a good "Dark Mode" feature without designing specifically for dark mode because Frames and other control components are not customizable at runtime.


Control Parts.png

LabVIEW could use a feature that's commonly used in C++, the "final" specifier for a class override method.  This would allow a child class to override a method from a parent class (or interface) and then prevent child classes of itself from overriding.  Currently, with large inheritance structures, it becomes difficult for developers to create child classes since so many of the methods can be inherited from.  The final specifier would allow you to create intermediate classes that define certain override functionality that does not need to be further overwritten and only pass on the ability to override methods that are important to child classes.

FInal Override.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. 

please do needful to enable Trim White Space function to accept string array input also

When you select several items the "right-click" functionality is available only for common operations.  One of those common operations for several controls and indicators would be to set the current value to default or set the default value to the current value.  Both of these are available from the menu option for multiple selections.


However, this option is removed from the right click option when multiple items are selected.  Why?  Simple UI configuration.

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




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.






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?