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



Please close if duplicate


I use (and abuse, especially combined with the Bookmarks feature) attached labels a lot

I would like a single comment to be attachable to multiple objects


It would prevent me from duplicating labels/comments


Multiple Objects Attached Comment.png



When building applications that use many different toolkits and classes, my build times can skyrocket.  It's frustrating that while i'm waiting for my application to be built LabVIEW is useless for development.  This is especially aggravating when I find a bug that takes 20 seconds to fix, but then building the application takes another 20 min.  To address this issue I propose that there be an option to launch the build process in a separate process from the IDE so that I  can continue working with my code in the meantime.  This could mirror the FPGA compilation process where it used to block development but now is separated out.


Why optional though?  For smaller applications the build process is very quick so if you can live with it I wouldn't want to always introduce the extra overhead that I assume would be necessary to lauch the build as a separate process.

Sometimes I want to insert a unconnected Sub VI on my panel into a some wire. I always end up deleting and reconnecting the wires to insert my Sub VI.


I miss a solution to quick insert a VI into a wire without deleting and reconnecting the wires.


I know we already have the option to use the QuickDrop with ctrl+I, but I miss a solution to insert a VI (that already exists on my panel) into a existing wire.

What about clicking on the wire and draging the Sub VI while pressing crtl+i?

When building an installer to let an application run on another computer one should select all the installers of products used in his porgram. This can be really tricky, especially to new users, that don't know if a VI was included in package A or B or if it's already included in the standrad runtime.


Therefore it should be possible to hit a button, that parses through the Application and determines which packages are used.


I though of writing something like this myself, but I can't be bothered Smiley Wink 

You'd just have to parse the Project, check all the VI names and relate it to a table that contains information, about where a VI comes from.


If this is a duplicate post, I'm sorry.

The issue of a modal window being left open during debugging, only to jump to the front when the top level vi is run, has been an issue in LabVIEW for as long as I can remember. I am certian that every developer at one time or another experiences this behavior. There are several work arounds to this issue such as "the old 3 fingered salute" (CTRL+ALT+DEL) and kill LabVIEW, programmatically setting the window modality, external VI task managers, etc... however all of them are workarounds to deal with the issue.


The crux of the problem is that any front panel specified as modal immediately becomes modal as soon as the VI is reserved for execution. This proposal would establish additional option to the VI properties dialog (Modal when Executing). Which would only initiate the modal property of the window when the VI was actually executing.


Modal When Runing.png


There have been several similar ideas related to dealing with window modality (see below) however I believe this implementation is different than anything I was able to turn up in a search.


Related topics:

When doing UI work, it can be quite frustrating rewiring hidden controls to the connector pane. You have to go to the block diagram -> Show Control -> go to front panel and wire it up then hide your control again.


I have seen a number of ideas proposing ideas such as hidden controls always being visible in edit mode or being able to link block diagram controls to the connector pane which I agree with and would also solve this.


My suggestion is that when you select the Wiring Tool on the front panel or click on the connector pane (to wire up a terminal) all the hidden controls would become partially visible and become connectable to the connector pane.




When you use TabControls in sizeable front panels,


you can only "Fit to pane" or "Scale object with pane"


to the tabcontrol itself !!!


But not for Its content ! Smiley Sad


Please handle the Tabpages as pane in order to be able to create userfriendly operator interfaces ! Smiley Happy


Thanks ...


TabPage Resize.png

When working with DVRs, i find it always a little cumbersome to create the DVR control and indicator for subVIs or data container (cluster, class).

I suggest to have a "DVR shell" available for front panel with no data type contained in the DVR. Dropping the DVR shell on the FP would break the VI, just like cluster and array shells already do.


The main reason for this suggestion is that dropping a data type in the DVR control/indicator already changes the DVR, so it is easy to "adapt" it to type.



Hi all,


I often find when programming with LabVIEW that I don't have room on my block diagram for free label documentation.  I find it hard enough trying to keep clean and tidy code and even harder document it well.  Free labels take up lots of room and I end up not writing good documentation because I don't have room for it.


My solution to this problem is a Documentation Node where you can write comments in a free label, minimize it and use context help to read it in the future.





It will be good, if the free comments on the block diagram (and/or front panel) have scroll bar.


Comments with Scroll Bar

Well as the title says...


In the string constant you are able to make a scrollbar visible but this is still inconvenient when only see 2 lines of your whole string when you have a string constant of 50 lines or so... and you 9 out 10 times you don't want to create a bigger field because it messes with your diagram.


Therefore a small popup with a only a large textfield would grately simplify things.


I came up with this idea when I was writing a error message and there wasn't much space to type the string in, I also had this,, idea in my backhead.


What do you guys think?



(sorry for my bad english, i will try to do my best)

it would be very useful to have direct Property Node for decorations.
This would avoid wasting time and having to implement a complicated code just to handle the resizing of decoration.








If I'm the first to post this Idea then I'll be shocked.

The Idea is simple. We all love programming in LabVIEW, and I'm sure that we've all at one time or another had a colleague, friend or family member ask if we know how to do something on the PC. The immediate thought is I don't know where to get the software to do that, but I could write a simple LabVIEW app  in a few hours that does the job.

E.G hunt through someone's PC and move all of the jpg files over a certain size to a specific location so they can easily find their holiday snaps.


You can't create this simple function for them, because if you do, and build an exe, they still need the Runtime engine.


Surely for REALLY simple stuff (File IO, basic comms stuff in the Base LabVIEW edition ...) - not DAQ or anything like that it is possible to create an EXE that INCLUDES the runtime components that it needs and is stand alone.


This would open up LabVIEW for the use of making quick gadget like apps for the office as well as test and measurement.


I can't se how this could be a bad thing.

Direct to PDF reporting is an extremely important feature to provide customers.  It cannot be relied upon that the customer has MS Word or the like installed.

There are a couple of LV PDF toolkits supplied by developers.  However, the problems with these include that they are (a) not updated or well-supported (b) buggy (c) have out-dated dependencies such as .Net 2.0 (d) restrictive licencing for deployment.

Good reporting tools are essential and NI should develop and support a direct to PDF toolkit.

Currently, it's possible to choose a unique default label position in settings of lavbiew.
All LabVIEW developpers day by day, for each elements, select labels and put it to left for a control or to right for a indicator ... 
It will be great if it will be possible to choose a default label position for indicators and a differente one for controls. 
So, when an element (indicator or control) will be added on the front panel. In the Block Diagram, the label will be at the right place !!!!!
Current Version of Block Diagram settings in LabVIEW
Great Version of Block Diagram settings in LabVIEW (next version)

I work with customers who use multiple versions of LabVIEW.  Being able to run two (or more) different versions of LabVIEW concurrently is a boon to my development and productivity.  However, identifying which version I am looking at or have open can be difficult.




Can YOU tell which versions I have on the taskbar?


To remedy this, I suggest a version badge be added to the taskbar icon for LabVIEW.  This will facilitate quick identification of LabVIEW versions.




Ohhh, its LabVIEW 2011 SP1 and LabVIEW 2012!


The Node "Close Reference" takes up too much space on the diagram.




                Please, a "Close Reference" smaller, like this :   SR2.png







The idea of viewing cluster constants as icons is a very good idea.


It would be very usefull to extand the idea to the controls and indicators.


I have to handle with big configuration clusters which take more than a window ... My need is to be able to iconify inner clusters in order to had a userfriendly view on my controls and indicators.


My real need is to be abble to view clusters controls and indicators in a TreeView way ... with the ability to expand / collapse some parts,

in order to highlight some specific parts. (The expand / collapse configuration should be keep in memory for each control/indicator instance)


This idea exists perhaps ...



I don't know how many times I've wanted to add Error in and Error out terminals to a VI retrospectively and have to visit the cluster palette twice to do just that.


How about (for those of us who don't yet use Quickdrop) an option to drop an Error Cluster pair (Both in and out) to save us a trip to the Palette?


That's it really.



Hi all


What I need is the possibility to auto index a 2 dim array by column or by row


With a right click at the tunnel to have this two options