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.

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.

Currently the fastest way to open the Properties page of a front panel element (control, indicator, decoration) is right-click >> Properties.

Holding down a modifier key (Alt, Ctrl, Shift, or a combination of these) while double-clicking on the front panel element would be quicker.

Notes

• Opening the properties page of front panel elements is a common, repetitive task, especially when creating complex UIs where the size, colours, display format, data entry limits need to be changed.
• Ideally the gesture would work on block diagram terminals too.
• This idea is very similar to New keyboard shortcut: Alt + double-click to open Properties in Project Explorer. The difference is that this idea addresses opening the Properties page of front panel elements, whereas that idea addresses project items.

Currently the fastest way to insert a Bundle By Name node into an existing cluster wire is to use the QuickDrop Ctrl + I shortcut.

Holding down a modifier key (Ctrl, Alt, Shift, or a combination of these) while double-clicking on an existing cluster wire would be even quicker.

Notes

• Inserting BBN nodes is a common, repetitive action when working with clusters. For example, when working inside the Message Handling Loop of a DQMH module.
• The gesture should work for class wires too, but only if access scope rules allow it.
• This idea is very much related to the "New gesture to create Unbundle By Name node (Ctrl + double-click when creating a cluster wire branch)". The difference is that this idea addresses inserting BBN nodes into existing wires. That idea addresses more easily terminating a new wire branch with a UBN or BBN node.

Thanks

Problem: When developing or inheriting a large code base it is helpful to know which VI has Automatic Error Handling (AEH) enabled and which has it disabled. Currently, the quickest way to get this information is to bring up the VI Properties window (pressing Ctrl + I) and navigate to the Execution page. This is tedious when done on large numbers of VIs.

Solution: LabVIEW should display whether AEH is enabled or disabled on the Block Diagram. For example, a grey triangle located in the bottom-right corner of the block diagram window could indicate that AEH is disabled, and an "error green" triangle could indicate that AEH is enabled, as seen in the screenshots below. This display method is just a suggestion - professional UX designers may well find a better method. I would be happy with any indication method that I could at a glance see on the block diagram window.

Idea expansion:

• Executing a single left click on the triangle (or any other indication method) would toggle the setting to its other value. For example, a single left click on the grey triangle would toggle the AEH to enabled and the triangle would become green.

We need a “modal when called” behavior where the VI is NOT modal when the VI is not currently running (being called). Otherwise, accidentally opening the VI during development while the main VI is running will make it so you can’t interact with any other front panels, block diagrams, or any other LabVIEW windows; and you’re stuck — you have to kill LabVIEW from task manager or cmd.exe (taskkill /f /im LabVIEW.exe)

My work-around is to add this little snippet of code that uses a Floating behavior in development and a Modal behavior in a built application (EXE).