LabVIEW Idea Exchange

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.

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.

Idea: The In Range and Coerce Include upper limit option should be selected by default.

Maybe it's just me, but when using the In Range and Coerce node I virtually always need to have both the Include lower limit and Include upper limit options selected. In approximately ten years of using the node I think I used a different configuration less than five times. It has entered my muscle memory that the first thing I do after dropping the In Range and Coerce node is to right-click it and select Include upper limit.

In my experience this point of view is supported by anecdotal evidence. For example, I have recently seen a large codebase that was rightfully using lots of In Range and Coerce instances. All of the nodes had been left in their default configuration (Include lower limit selected, Include upper limit unselected). However, after inspecting the code carefully I came to the conclusion that the intention was for all of the nodes to perform an inclusive comparison on both sides. This was confirmed by a conversation with the original code author. The author had simply been unaware of the true behaviour of the node (he had assumed it performs inclusive comparison on both ends) and was unaware of the right-click options!