LabVIEW Idea Exchange

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.

Hi,

When I use array constants on the block diagram I often expand them to show how many elements they contain - I even expand them one element further than their contents to leave no doubt that no elements are hiding below the lowest visible element:

Often it's not so important to know how many elements are in the arrays, nor even their values (one can always scroll through the array if one needs to know). But it can be very important to not get a false impression of a fewer number of elements than is actually present, for instance when auto-indexing a For-loop:

To be able to shrink array constants to a minimum size while still signalling that they contain more elements than currently visible, it would be nice with an indicator on the array constant when it's shrunk to hide elements (here shown with a tooltip that would appear if you hover on the "more elements" dots):

The information in the tooltip would be better placed in context help, but the important aspect of this idea is the "more elements" indicator itself.

Cheers,

Steen

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

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.

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.

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: