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

I'd like to suggest to add a small button to the header of a disable structure.

Clicking to this button would enable the currently visible case while all others should be disabled automatically.



Wire : Right Click --> Visbile --> Label  (Its void Now )


1.png                                  2.png


Solution : It can take the control Name as default label of the wire,  instead of  being Void





Not sure if this idea is already proposed. 



(This is different and less controversional than  this related old idea)


Arrays of timestamps only contain legal values and can even be sorted. We can use "search 1D array" to find a matching timestamp just fine.


As with DBLs, there might be a very close array value that is a few LSBs off, but well within the error of the experiment so it is sufficient to find the closest value. We can always test later if that value is close enough for what we need or if "not found" would be a better result.


If we have a sorted input array, the easiest solution is "threshold 1D array" giving us a fractional index of a linearly interpolated value. For some unknown reason, timestamps are not allowed for the inputs, limiting the usefulness of the tool. One possible workaround is to convert to DBLs, with the disadvantage that quite a few bits are dropped (timestamp: 128 bits, DBL: 64bits).


Similarly, "Interpolate 1D array" also does not allow timestamp inputs. In both cases, there is an obvious and unique result that is IMHO in no way confusing or controversial.




IDEA Summary: "Threshold 1D Array" and "Interpolate 1D Array" should work with timestamps.




Right now, if you happen to use the right colors, LabVIEW will change the text color on a Boolean.  But, if you don't pick the right colors, LabVIEW keeps a single text color.


Boolean Text.png



This would probably be fine IF LabVIEW allowed you to have multiple text colors, but you can only choose one:


Boolean Properties.png


But, as you can see, LV only supports one text color.  I propose that LV support two text colors (ON and OFF).  Obviously LabVIEW has the ability to change the color already since it will do it in the right circumstances, but it would be nice if LV gave us control over it.


In my use case at the moment, I am trying to make a custom illuminated button which the text on the button should be grey went off, and yellow when on.

The Property class, which represents the property node, has a property called All Supported Properties which ideally would show all the properties supported by the class the property node is linked to.


The problem is that it doesn't. If you have nested properties which come from another class (for example, the properties for the caption which can be selected by opening the pull right menu, as seen in the top image), those properties aren't returned when you call the property, and instead you just get the property for the caption reference, as seen in the bottom image, where the ControlIndex property is shown immediately after the Caption property.





Instead, I want either this property or a new property to return all of the nested properties as well, just like you get in the UI.

This would be useful for setting properties using scripting and alternate UIs (like this one or this one, which can't work today, because they can't get the full list of properties).




When setting up In Place Element structures, the current work flow is:


  • Drop the structure
  • Right click, add the node you want
  • Wire the reference / array / variant in

It would also be nice to wire the references I want to use to the border of my IPE structure, right click on the tunnel (c.f. for and while loop auto-indexing context, or shift register/tunnel) and select from a sensible list of incoming element types relevant to my incoming wire.

This would be fantastic to see alongside similar ideas such as this or this.


Instead of having to open the "Display Format" window everytime you want to drop a control/indicator/constant with a special format value (i.e. 2400000000 as 2.4G) make the control/indicator/constant automatically set to whatever format you put in. For example




Typing in 2.4G sets the Display Format to "SI notation".

Typing in 2.4E9 sets the Display Format to "Scientific"

Typing in 2400000000 sets Display Format to "Automatic formatting" etc



For about a decade and a half I have consistently changed the default block diagram grid spacing to 4. Why, to match the shift arrow moves.  Hold it!  Why not make the shift arrow moves equal the grid spacing?  


Yes, I a genius!  The Kudos button is lower left!

If you attempt to write an Enum to a TDMS Property the function will return error -68007.  "This channel or property value contains a data type that is not recognized by this version of LabVIEW."  Reading and writing Enums as Channel Data however works just fine.


There are a few work arounds for writing and reading TDMS properties as Enums, attached is one such example where we write the value as a string, then have to convert that back later.  There is extra work involved because we need to generate an error if the string value doesn't exist in the enumeration provided.




This idea is to ad native Enum Reading/Writing to TDMS properties.

I find often the need of creating array indicators with many elements, and of labelling them is a way which allows easy identification of the element index.

Normally the labels of the elements can be made visible, like in the left example shown:


array index labelling example


One way of doing it, if the array has a fixed size, and all of the array is shown at once, is to juxtapose a set of text labels identifying the elements. Tedious to build.


If the array changes size, if it is larger than shown, if it is supposed to be scrolled on the FP, static labels are useless. Currently the label of the element can be made visible, but all elements share the same label. The index display of the array can be shown, but it relates to a single element, which makes cumbersome to identify elements of long arrays.


I usually resort to more sophisticate contraptions, like arrays of clusters, each composed of the element in question and of a numeric indicator; or to two parallel array indicators, one for the elements itself and one for the indices. Both solutions are more cumbersome to build and to size and align equally; the index content has to be prefilled and maintained in sync when array elements are added or deleted (programmatically or via contextual menu); in the second case, a lot of events have to be trapped programmatically, for instance to maintain synchronism when the main array is scrolled.


What I would like to have is an additional label natively visible, showing the element index, like on the right.

The labels could be made optionally visible with a contextual menu ---- left click->visible items->index label.

Options (perhaps properties) in order to set the value of the first element (e.g. 0 or 1 or any other value) and the step value if different than 1 would also be useful. Standard options about location and orientation of the label with respect to the array element would apply.

When I create a public API method for an actor it's very nice to have the VI description populated for use with the Context Help window:

Method CH.png


However, once you create an AF message from that method, other actors will generally be using the Send [VI Name] method instead of the payload method itself and the context help for the Send method is decidedly less useful:

Send Method CH.png


Wouldn't it be nice if the send method automatically appended the payload method's VI description so it looked something like the following?

Better Send Method CH.png


I've actually written a VI package that will do this, but in order to accomplish it I ended up modifying the MessageMakerProvider and MessageRescripter project providers. It's workable, but it's really only reliable for the one specific version of LabVIEW in which it was developed so it'd be much nicer if NI implemented this out of the box.

LabVIEW to Android .apk for apps or to Apple mobile

Dear Hot Shot Devs! 

thousands of us want to be able to build a mobile app from LabVIEW!!! 

Can you imagine??


All that power with full responsive features on any device, like Swift and Android Studio??


you can “hook into” those tools to let us design the User Interface and evening do Bluetooth and Wireless with all’s y’all’s stacks and wizardry!!


Consider me as an Alpha tester.  I know what is needed. Let me know the plans!


I have been using LabVIEW since before rev 3.0 when we could actually talk to Dr G!! 

great work you are doing. Sometimes I do not enjoy the “abstractions” you do to make it easy. Kind of liked the good ole “bit banging” direct link to Comms and I/O but I understand.  

contact me at


Right-clicking on a VI in a project and selecting "Find -> Callers" doesn't list any .lvtest files which call the VI in question.  I think there should be a relatively easy way to find which unit tests call the VI.  I use Find -> Callers when I'm refactoring, and want to know what code might be impacted by a change.  It'd be nice to quickly find the unit tests which also call the VI.


Option 1) Have Find -> Callers include .lvtest files in the results alongside calling VIs.


Option 2) Add a separate Find -> Unit Tests


Annotate palette items with dynamically generated keyboard shortcut characters. The keyboard shortcuts should be such that users don't have to use two hands to type them out. Typing out the shortcut will close the palette and put the palette item on mouse cursor. If the shortcut is on a palette folder, the palette will remain open and show content of the folder. 


This is a great symbiosis between mouse and keyboard and will increase user's coding speed by reducing mouse travel.


There should be a couple of options for opening the palette via keyboard shortcuts for a complete experience- 

  1. Shortcut to open main palette. Similar to right click on blank space. 
  2. Shortcut to open recently or most used items palette. 
  3. Shortcut to open parent palette of node under cursor (or last node dropped). 
  4. Shortcut to open palette related to datatype of wire under cursor.

Here is a visualization of how the annotations might look like- 



Note that all the shortcut characters are on left side of the keyboard, and could be typed one handed operation by a touch typist. It will be easy to configure the tool for left-handed people and concentrate the keys on right side of the keyboard. Also, the letters have been selected in a way that the two keys are on separate fingers for faster typing.


Comparing to quick drop feature-

  1. Quick drop requires user to recall from memory. User has to either remember the short name or the full name of the item. With this idea, the shortcuts are right in front of the user.
  2. Characters of full name of the item on quick drop can go all over the keyboard. User either has to move one hand around which will require looking at the keyboard or move the mouse hand to keyboard. With this idea, it will be easy to control the shortcuts to be on one side of the keyboard.

    Note: Short name of items in quick drop are concentrated on left side of keyboard, catering only to right-handed use. Not sure how easily the short names can be configured for left-handed use.
  3. Overall this idea supplements quick drop. It speeds up a few happy paths.


  1. Figma. It is a website design tool and has a tiny palette with rectangle, circle, line, text, etc. It has keyboard shortcut for each of the palette item – R for rectangle, L for line, T for text, and so on. E.g. typing R brings the rectangle on mouse cursor. It has a small palette so remembering the shortcuts is easy. This idea cannot be directly ported to LabVIEW because of the billions of palette items. 
  2.  Vimium C Chrome extension. This extension enables experience of vim editor in browser. One of the features it has is annotating links with dynamically generated keyboard shortcuts. Typing out the shortcut keys takes you to the link.

Combining both gave origin to the above idea.

If you have mulitple versions of LabVIEW installed, some of them show up in the "Open With" menu, but regardless of which item you select, the VI will always open in whichever version of LabVIEW was opened most recently.


Example: if I opened a legacy VI in LabVIEW 2009, closed that version of LabVIEW completely, and opened another VI using the "Open with" menu and selected LabVIEW 12..., LabVIEW 2009 is relaunched and is unable to open the VI because it should have launched in LabVIEW 2012.




The current workaround is to add all installed versions as options in the "Send to" menu, but this is not nearly as intuitive as using "Open with" would be.


Data Type Representation Pallette


Can the the options on the data type Representation pallette be changed from grey to match the color of the numerical icons and terminals?


Thank You!

Melissa McQueen

The Tree- Control and the Multicolumn Listbox support the presentation of a Symbols per row. But there are a lot of cases where there is needed more than one symbol per row. One very common scenario is the display of various states (Calculation completed: Checkmark; Results written to file: Checkmark; Assigned Application to open file: App-Icon...). NI does this already in the "Example Finder" window, so it is obvious there is a need for this feature.

I think it is a good practice to hold a pool of symbols, attached to the control, like NI does currently with the Trees and MCLBs. And for performance reasons there could still be the possibility to determine the columns to be capable to display symbols.

So from the LabVIEW programmers point of view there could be added the following properties / methods:

  • Symbol-Displayable Colums (property, read/write), (1D Array I32): Gets or Sets the indices of colums, which can show symbols and reserve space when the property "Visible Items->Symbols Visible" is set to true
  • Active Symbol- Column (property, read/write), (I32): Gets or Sets the Column-No which has focus for the next "Item Symbols"-property operation.
  • Set Column- Symbols (method, takes an I32 as Index for the Column, takes a 1D-Array of  I32 as Symbol-pool indices): shortcut for setting the Property "Active Symbol- Column" followed by setting the Property "Item Symbols".
  • Get Column- Symbols (method, takes an I32 as Index for the Column, returns a 1D-Array of  I32 as Symbol-pool indices): shortcut for setting the Property "Active Symbol- Column" followed by reading the Property "Item Symbols".

This should provide compatibility to the current handling of symbols since the property "Symbol-Displayable Colums" defaults to [0], so if "Item Symbols" is read or written to, it is meant to use the first column, which is status quo.

Currently, you can place a probe on a wire while developing, which is an indicator of the data on a wire. I want the ability to CONTROL the data on the wire, with a data forcing mechanism.


The implementation would be very simple... right click on a wire, and in the context menu the option "Force" would be right under "Probe." It would pop up a window of the forcing control, and while the VI is running and forcing is set to "Enable", the programmer can control the values that pass on the wire. If the force window were set to "Disable", the data in the wire would be completely controlled by the VI's logic.




I think the implementation by NI could be trivially simple. If you only allow a forcing control to be added during edit mode (not while the VI is running), the force could be added as an inline VI (as denoted by the green rectangle on the wire). The code inside the inline VI would be as follows, and the front panel would be "Data Force (1)" as shown above.




Of course, if you could add a force to a wire during runtime like probes, props NI. But I would be PERFECTLY happy if you could only add these force controls in edit mode prior to running.


One level further (and this would be AMAZING, NI, AMAZING): enable and disable certain parts of the cluster that you would like to force and allow the other elements to be controlled by the VI logic. I made the example above because it would be very natural to ONLY force Sensor1 and Sensor2, and letting the output run it's course from your forced input.



i propose to add a "Key Focus" event for each control. We already have Mouse events (leaving, entering) - but when the user (or the programmer) prefers the keyboard (with proper tabbing setup) you have to poll each interesting control for it's "Key Focus" property to initiate a user event...


So please:

Add a "Got Focus" (and additionally a "Lost Focus") event to the event structure!

I search the idea forum and I see many Labview Upgrade suggestions as "DECLINED".  

I know there are others out there like me, I HATE upgrading Labview.  All the time required to update your custom configuration takes weeks.  Heck, Labview upgrade isn't even smart enough to know all the software you're entitled to install...instead you have to force Labview to download and install your paid software individually.


Here's the deal, most of us don't have the time to upgrade because of all the maintenance we do to support our software.  For instance, I have a paid Maintenance Agreement (as I do every year), I have been working in LV2015 and now it's time for me to upgrade my computer and I'm installing LV2018.


My wish, Have National instruments create a tool that would allow you to export all your custom settings, device drivers, and software requirements, etc..., so you could import these settings into a new version of LV.  Making the upgrade process easier with a single tool.

Since it's so difficult to upgrade, I often wait 3 years or more before I try to upgrade.  If it was more seamless to upgrade, I'd probably upgrade every release!  


Anyway, we are all so busy we don't have the time to search these forums, so this request will be DECLINED too.


Perhaps NI should accumulate all of these requests to Upgrade and total them as one.  Each individual request dies in a year because so many people are sticking with what works...often older versions of LV.


Sure, NI has a few upgrade tools, but, nothing that leaves you upgraded to the latest version of Labview without missing a step.