LabVIEW Idea Exchange

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.

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.

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

Notes

• Replacing a node via Right-click >> Replace >> selecting item from palette results in the same outcome as replacing via QuickDrop. This idea should apply to both replacement methods.
• Replacing a VI via either QuickDrop or right-click behaves correctly. The new VI label is visible only if the old VI's label was visible. In effect, the new VI retains the "Label >> Visible" setting of the VI that was replaced, which is desirable.
• This idea is somewhat related to the following idea: "Show node names when dropped" option

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.

Using "Edit Palette Set" is cumbersome and painstaking.

Specific use case example:   I create a class library that has an embedded menu file that I want to distribute as a compiled packed library (PPL) or even as a source code distribution for re use by other developers.     To make the mnu available in the functions palette, you have to manually recreate the menu file to link to the versions of the functions inside the distributed functions, which is painstaking for a larger library.

It would  really nice if we had the ability to generate or easily edit mnu files.  In the example, a simple search and replace of the paths that the functions in the palette link to would work