LabVIEW Idea Exchange

Big clusters that go beyond the limit of the FP are annoying, especially to resize them automatically and reorder the controls.

Here are a couple of improvements that could be made:

• "Reorder controls in cluster..."
  • Allow user to scroll while re-ordering the controls to have access to all elements instead of having to do it in multiple time.
  • Shortcuts like Escape and Enter should respectively cancel-exit and validate-exit the reordering phase
    These are pretty standard shortcuts and already widely used within the Labview environment
• "Autosizing"
  • Autosize to "Compact". Where instead of aligning all element vertically or horizontally only, they would be in the "most compact" (to be defined) possible configuration to simplify the access to all info in the cluster.
    For instance compacted in a square way, sorted by class (Booleans/numerics/strings etc.)
    I understand that this one might be more complex, but it would be really helpful in my opinion
    
  • Less important (to me): In Edit Mode, in case a cluster is autosized to "none" and some items are hidden outside for whatever reason, the developer should be notified somehow. For instance the same way than for strings 
    
  • (In the same case than above, allowing scroll bars could be interesting in some situations.)

-Vincent.

I'd like there to be an option to show some kind of indicator on string controls that you aren't seeing the entire string. This should also apply to string constants on the block diagram.

I searched for a similar idea, but couldn't find one. Let me know if there is already a similar idea.

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 function

Since a few years, we have native support for Map and Set in LabVIEW.

How about adding a DataFrame type similar to other programming languages (possible even with a native interaction with Python)?

A DataFrame type would be a 2D value where columns can have different datatypes. Currently, one needs to build around this by creating an 1D array of a cluster (or class) type.

Access to the data would be with numerical indexing for the rows and field access (like in a cluster) for the columns.

KR, Benjamin

History probes are a very useful tool in LabVIEW. However, one improvement can be made to them when working with enums. Currently, the values in enum history probes are returned as numbers, as shown in the picture below:

It would even be more useful if enum history probes returned values in terms of the enum item names rather than the numeric values associated with them, as shown in the picture below.

Currently, it's a crapshoot when you drag an ant trail selection box around items on your FP or BD. It's truly an art to become good at selecting objects in LabVIEW - we all learn "hot spots" to place our selection rectangles, and we all heavily rely on the "Shift+Click" method of adding or removing objects from our selection. Below is an example of what actually might be selected when dragging a selection box:

All horizontal wires were selected down to "ABCDEF", even though just a very small portion of the visible wire was inside the selection box. It's not intuitive to try to not select wire that is hidden behind the Unbundle.

I propose a method that mimics selection in some graphics editing and CAD programs: the idea of "Enclosed" and "Inclusive" selections. An Enclosed selection is made by dragging the mouse from L to R. This operation selects only the objects THAT ARE COMPLETELY ENCLOSED by the selection box, ignoring objects that are partially outside the selection (the red arrow is not part of the BD, it merely represents the motion of the cursor):

Alternatively, if you drag your mouse from RIGHT to LEFT for a selection box, you select every single object that is fully or even partially contained within the selection box:

Voila! Selection is now a TAUGHT SCIENCE instead of a LEARNED ART!

Currently, when you right-click -> "Make Type Def" on a control / constant in a library VI, the new unnamed type definition is created outside

the library.

Also, it has the default control icon: 

instead of a library control icon:       

This leads to 3 additional tasks:

1. Drag and drop the control inside the library from the project explorer.

2. Edit the control icon to make it have the library control icon (with the horizontal slider glyph).

This is annoying because you need to copy it from another library control icon.

3. Go to the library properties and make "Apply Icon To VIs".

Bonus bug: If your new type contains a library-private subtype, the new control magically disappears from the project explorer when you click on it.

In comparison, the "Create SubVI" function works perfectly inside a library, i.e. it creates a VI inside the library and with the icon banner.

I think the "Make Type Def" function should behave the same to make library development more coherent and intuitive.

See this github repository for a more complete proposal and an example implementation that gets us closer to achieving this in LabVIEW.

Some languages like Rust and Zig have a feature called Tagged Enums (or Sum Types) that allow you to create a data type that can be one of a few different types where there is a name associated with each type. In LabVIEW, however, Enums are limited to consecutive numeric integer values -- there's no way to associate a type with each named value.

The power of combining an Enum with a data type for each value is that we could potentially use a Case Structure as a switch statement with type assertion and data conversion built in! This would allow us to create robust, type-safe code that is easier to maintain and understand.

See this github repository for a more complete proposal and an example implementation that gets us closer to achieving this in LabVIEW.

Instead of the two step process of wiring an input on the Connector Pane and then changing the terminal setting to Required through the right-click menu, holding down the Ctrl key while wiring the input will automatically set the terminal to Required.

I know there's a LabVIEW option to set all terminals to Required as default, but I usually use a mix of Required, Recommended and Optional.

Hi guys,

I'm missing some very fast way how to create cluster out of selection. It could be done as it is shown here:

I think since LV developers became familiar with Every GUI Programmer's Dream they are ready for the next step...

Currently if you right click on a subVI from the block diagram and choose properties, it brings up the Object Properties dialog.  The only options you can change there are label options, which can easily be changed in the "Visible Items" submenu.  I can't think of one time when this has ever been what I wanted out of this action.  Instead, I think this action should open up the VI Properties Window for the VI.  

Suggest adding functionality to the event structure when handling Value Change events, so that the user can tell whether the source of that generated event was via a write to a Val(Sgnl) property node, or via a Front Panel change made by the user. 

This could potentially be achieved (albeit with backwards compatibility considerations) by defining an appropriate enum constant for the eventsource.ctl which available in the "Source" field of the Event Data Node (currently has "LabVIEW UI, ActiveX, User Event, and Other <>..." as the only defined constants).

More discussion and rationale is in this community topic:

Solved: Re: UI-Triggered Event vs. Value (Signaling) Event? - NI Community

Integrating markdown, asciidoc, whatever. This would help eliminate a step for most of us lowly third parties making docs for our software. A built-in browser would be nice, or just opening the doc straight away in a compatible viewer would be fine.

Loading the NI website's page for the help doc takes ages. This could also be a way to locally host vi docs and have a built-in browser-like display of help files.

I frequently find the context help information not detailed enough and get frustrated waiting for the website to load. If it was a one-stop shop markup-based doc, that's meaningful time saved.