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.

There are times when I leave a VI with modal properties open and then I run the main application that also calls this VI if opened in the development environment. This locks all running windows due to the modal VI. I propose a button in the taskbar that aborts all running VIs OR perhaps a list is opened on right-click of all running VIs 🙂

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

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.

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.

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.

Please implicitly consider array index during index / replace elements in In Place Elements Structure if I am starting from Index 0

Present method:

Expected method:

[admin edit 2021-02-24]: placed images in-line with text and removed them as attachments