LabVIEW Idea Exchange

Community Browser
Top Authors
Showing results for 
Search instead for 
Did you mean: 
Post an idea

When using the Rearrange Cases window with a Type Specialization Structure, the case list only shows either Declined, Accepted or Ignored. This makes it difficult to know what cases are being reordered. Similar situations occur with a numeric case selector (just a list of numbers) and event cases (dynamic events with the duplicate default wire labels).



This idea is to add the subdiagram label of a case next to each entry in the case list. This would add some context to each item, and make rearranging cases quicker and less error prone.



Alternately (or in addition to the above) would be the ability to preview the contents of the selected case / subdiagram, much like the preview when selecting a dynamic dispatch VI in a class hierarchy. This would be useful for cases with no subdiagram label, or in the case of the type specialization structure, allow visual comparisons of which case should be evaluated in which order.



On a block diagram string constant, there are shortcut menus to change the display style. Currently, we can change the style without making the selector visible. That leads to bugs when later programmers do not realize that the string they are editing is in a different mode. Currently, we have to choose "Visible Items >> Display Style" first, which makes the shortcut menu items useless (because then we just use the now-visible selector ring). In the future, when we change the style through one of the shortcuts, I would prefer that the selector automatically becomes visible. 



This is a follow on to this idea. After terminals are wired to growable nodes. Make it easier to move and reorder the terminals. The switcharoo tool exists if there are only two terminals but it is difficult if there are more. 

I suggest making it easier with a keyboard/mouse combination or mouse long hold or something like that, to select a terminal. Then let the user drag it to another terminal and drop it. If that terminal is wired swap the selected wire and the one dropped over. If not wired, move the wire connection to the terminal dropped over. 

Add another option to the Search Scope to Ignore VIs in user.lib

That's it!!  😁

Search Scope - user.libSearch Scope - user.lib

Currently if you draw a diagram disable structure around a section of code any wire coming out of it will be set to "Use Default if Unwired". This is almost never the desired behavior, and can easily lead to bugs if people forget to connect wires through on the Enabled case. The VI should be broken until the developer makes any necessary changes in the Enabled case. Diagram Disable Idea.png

In a simple project, the main entry point into an application is usually easy to find:



However, for more complex projects (particularly those utilising libraries/classes) it may not be obvious where to begin:




LabVIEW should provide a mechanism for tagging one or more VIs such that they are easily accessible to someone unfamiliar with the project. 


One possible implementation:


  • Display tagged items as links at the top-level of the project.
  • Links would be pinned to the top row
  • Link names would be editable and need not correspond to the name of the item they link to. (e.g. The link "main" may point to "")
  • For minimal confusion, developers should be encouraged to name the first link "main" (or similar)
  • In principle links could point to anything interesting, not just the main VI.
  • Double-clicking a link should open (or navigate to?) the target item


Hopefully low hanging fruit? I'm constantly checking the error list when working in a VI that's part of a broken class hierarchy to see if the VI itself has errors or if it's just due to a hierarchy error or dependency error. I often repeatedly check it to confirm if the VI I'm currently working in has the errors and could save a bunch of time if something was different about the broken run arrow and I only had to glance at it to confirm I can move elsewhere in my development as expected, or continue to the error list to see what's really broken.

Many of these VI properties are "Run-time" writeable.  They should not be set while the vi is in an "Idle" state 


Screenshot 2023-05-12 191049.png

Not every bundle is linked to a Typedef. It would be very useful to automatically inherit the names of previously named wires into bundles.

Showing the Current and Proposed behavior for name inheritance in the bundle functionShowing the Current and Proposed behavior for name inheritance in the bundle function

As part of everyday class development, I often want to track down everywhere where certain class data is being used. Would be convenient if there was a shortcut for doing this...perhaps something like:





So, i just changed a case from a string input to a boolean input. Ofcourse it gets broken with a red "1" in the case selector. That's logical. 

Now i need to select the case selector and write False, then switch to the other and write True ...  

Once both cases are correct i can r-click and switch them with a "Make this case False".


Improvement suggestion:

If having a boolean input, the Make this case True/False should be active for all cases always.

Even if you have multiple cases (it'll still be broken and you'll have to clear the extra cases)

Since 1986, when LabVIEW first launched, there has been one constant.  Icons are 32x32 elements. 


That made sense on 17inch CRT monitors.  There have been improvements in displays since then but, no corresponding improvement to the Icon resolution. 


Isn't it time to change that?

I should be able to modify a class with no private data to be an interface and vice versa. This post indicates it's not readily possible currently. But, the documentation for interfaces is sprinkled with statements that they should be for the most part interchangeable with classes.

I have wasted days weeks of my life tracking down why dependencies are loaded in LabVIEW.


This is because the "Why is this item in Dependencies?" tool isn't particularly useful in larger projects.  And it isn't particularly useful because it highlights any file in your project (and not in the dependencies) that is dependent (no matter how indirectly) on the chosen file.


In this example, if I click on "Why is this item in Dependencies?" on library C, I get pointed to a VI in the project (A.a) which has a very indirect dependency on library C.



It would be far more useful to me if I instead only got shown the VIs that directly depended on my dependency (even if they were in dependencies themselves).  If I then wanted to follow this up the chain, I could just click on "Why is this item in Dependencies?" again, but on the found item.




When using LabVIEW in combination with other languages, it would be really nice for LabVIEW to be able to read from and write to the stdout and stderr streams. For example, when writing a dll in C that is to be used by LabVIEW, it would be really nice to be able to see the output and error streams from within LabVIEW. As it stands you have to jump through hoops in another IDE or create a log file or some other workaround if you want to see what might have happened inside the dll to cause it to crash.

Clusters can be added together using the "Add" primitive:


Why not support adding them together in the same way using "Add Array Elements"?


I think it would be a good idea to enable running code formatter, like Darren's Nattify VI, automatically when saving a VI. Currently, most IDEs have built-in formatting tools which promote a unified, clean code style, and programmers don't have to worry about it because the code is automatically cleaned up before saving. I think a similar function would be a great addition to LabVIEW.


In Visual Studio it is called "Run Code Cleanup profile on Save". You can also configure different profiles (different styles or flavors). This option would be nice to have.


It would be great if it were possible to reduce the amount of time spent cleaning up LabVIEW code while keeping the code in decent visual condition.

VIMs are awesome but when wire inputs are broken they aren't awesome. They'd be awesomer if there was a way to specify that when specific frames of type specialization structures are active, there is a way to get specific strings added to the error info for the caller. Having a way to add custom strings to VIMs would overcome the general "An unsupported data type is wired to this subVI node." error string we're currently given. This can also help differentiate between LabVIEW breaking during type prop for odd (bug) reasons and properly invalid inputs... Do I need to just delete a wire and re-wire the input or do I need to hope the developer provided good VI documentation?


With some additional frames in Type Specialization Structures and maybe something like a subdiagram label but instead it could be a error reporting field at the bottom of a frame, it would be much easier to provide meaningful information back to a developer such as "GUID input only accepts GUID.ctl or a String". Then if the caller breaks with the unsupported data type error for the VIM, error details from the currently active TSSs can be concatenated to the Details string displayed in the Error list dialog. Alternatively, each error message found in TSSs could be separately listed in the Error list.


My 10 second idea:

TSS Error.png

 Resulting in the Error list perhaps showing it as either an error or concatenated into the Details:

TSS Error list.png


It would be nice to easily find objects that prevent a structure with "Auto Grow" from becoming smaller in size.  For example, the Add function in  the True case in the simplified example below.





Estimate and show the Time Remaining during LabVIEW Installs, using selectable and realistic time units: