LabVIEW Idea Exchange

A recent version of LabVIEW has introduced the ability to make the Iteration Terminal of For Loops and While Loops invisible. This is a useful new feature, I use it often, thanks for implementing it.

The problem is that currently the only way to toggle the visibility of the Iteration and Conditional terminals is to right-click, navigate to Visible Items, and select the desired option. This can take one or a few seconds, which is slow. Moreover, sometimes it is necessary to right-click and access the menu twice in quick succession. For example, for loops are created with their Iteration Terminal visible and their Conditional Terminal invisible. If one wants to invert the visibility of each terminal (make the Iteration Terminal invisible and the Conditional Terminal visible) one needs to access the same menu twice. This can take a few seconds.

Solution: The Iteration Terminal and Conditional Terminal configuration of a loop can be set via a single keystroke. For example, pressing "0" would make both terminals invisible (if possible). Pressing "1" would make the Iteration Terminal visible, and the Conditional Terminal invisible. Pressing "2" would make the Iteration Terminal invisible and the Conditional Terminal visible. Pressing "3" would make both terminals visible.

Notes

• While keys "0", "1", "2", "3" are proposed above, I would be happy with any other keys, or key combinations, being chosen as the trigger of this action.
• The digits 0/1/2/3 were chosen as they can represent a two-by-two binary table of the visible/invisible states of the two terminals. I.e. 00 = both terminals off, 11 = both terminals on, etc.
• Pressing the key should have no effect in those cases where the requested action is impossible. For example, a While Loop must always show its Conditional Terminal. Pressing "0" could make the Iteration Terminal invisible (if it is not wired), but would have to leave the Conditional Terminal being visible.
• This idea sits in the "increase developer productivity" category. I want my IDE to enable me to be as productive as possible. Every second matters. In fact, even tenths of a second matter.
• This idea is similar to the following: Pressing the "L" key should toggle label visibility. These ideas were posted on the same day.

Sometimes, it would be useful to view string constants as icons to save space on the block diagram.

1_String Constant Right Click.png

2_String Constant Details.png

Every now and then, I stumble upon the following error when trying to use the "Match Regular Expression" node in a inlined/malleable VI:

raphschru_0-1727975484834.png

If I understand correctly this discussion, this is because it is an XNode, which is currently (or definitively) not supported in inlined VIs.

But further in the discussion, it is said that an exception was added in the compiler to allow inlining the "Error Ring" XNode.

My idea is to consider adding the same exception for the "Match Regular Expression" XNode, or make any modification that would result in this node being inlinable.

Also, there is nothing in the generated code of the "Match Regular Expression" XNode that prevents inlining!

All it really does is using a CLFN to call function "MatchRegExpEfficient" from the LabVIEW library.

Regards,

Raphaël.

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:

Enum History Probe.png

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.

Enum History Probe.png

Error 1003 occurred at an unidentified location

Possible reason(s):

LabVIEW: (Hex 0x3EB) The VI is not executable. This error may occur because the VI is either broken or contains a subVI that LabVIEW cannot locate. Select File>>Open to open the VI and verify that you can run it.

The RT Image contains a secret subset of the host's vi.lib. Excluding vi.lib is the default build setting and is recommended in LabVIEW: (Hex 0x6C0) When Deploying Source Distribution to RT Target - NI

When running deployed code, we get error 1003 if the RT Image does not contain a .vi or .ctl that exists in the host's vi.lib. My tests showed that this can likely be a single .ctl.

I ask NI either to publish which .vis and .ctls each RT Image contains, or, even better, to create a log that helps identify which .ctl or .vi is missing. A log with even an obscure signature of the item that failed to load is better than having no information. The alternative—disabling “Exclude vi.lib” because of one or two missing files in the RT Image—leads to unnecessary bloat and code duplication for every single plugin deployed.

I ask NI to either publish which .vis .ctls each RT Image contains or better to create a log which can help identifying which .ctl or .vi is missing. A log with an obscure signature that failed to load is better than no info here. The alternative of not excluding vi.lib because of one or two missing files in RT Image is effectively unnecessary bloating and duplication of code.

I use the conditional disable structure in my projects to turn debug options on and off.

At the moment before every build I have to go into the project properties and make sure that DEBUG variable is set to FALSE and after the build I have to change it back.

You can get around this by automating you build but an option in the build specifications would simplify this.

It would make life much more convenient if there were a list of the available (non-system) conditional disable symbols in the application builder dialog where the appropriate variables for the build could be set. This would also allow for a simple duplication of a build spec to have one with DEBUG=TRUE, and one with DEBUG=FALSE.

The connector pane is a very useful feature for defining what the parameters for the VI are, therefore how it interacts with its environment.

On the other hand, the development experience did not age well. The 32x32 icon that is divided into smaller areas based on the pattern selected for the VI feel small on today's screens. On top of that most of the functionality is hidden behind the context menu.

This feels like a lacking experience for a crucial feature, but we grow accustomed to it, there we do not complain. But that doesn't mean things cannot be improved.

I would personally prefer a new window being opened when I want to edit the connector pane. The pane itself could be represented with 5x magnification (or even better, user selectable): 160x160 pixels.

On the pane, we could have a dedicated drop down that facilitates the selection of the pattern.

On each connector we could have a border representing its current state: Dynamic dispatch/Required/Recommended/Optional.

Cycling trough these states would be available on left click, for example, and reversing the direction with a shortcut, like ALT + left click.

Connecting the front panel terminals to the connector pane could be done by dragging and dropping to the desired place. To make sure that mistakes do not happen, the drag operations shall not move the front panel controls on the panel itself.

To make the workflow as smooth as possible buttons could be added to Apply the new connector pane, Apply and reorganize the front panel, Reorganize the front panel or Cancel the whole operation.

To make sure that we don't lose existing functionality the CTRL + left click shortcut shall keep the swap terminals functionality (a.k.a.: switcheroo).

Removing controls from the connector pane could be done by the right click, or left click for selecting the terminal and then using the Delete button on the keyboard.

Other operations inside the context menu, like the rotate by 90 degrees, add terminal, remove terminal, etc. could be made available via the menu of the window. I personally use these less, but if there is need for them, then we can discuss how they shall be presented on the window.

Since this idea was formulating over a long period of time in my head, but by no means lot of tought put into it, I'm very open to discuss the details. And, by no means the only or best solution to improve the Connector Pane UX.

At the moment, if I want to review my search results, I'm required to double click each item. This opens the diagram (usually) and the front panel. I then have to close them, or I might end up with dozens of open windows.

Of course I could use CTRL+G, but I'd still need to clean up the opened windows.

Another slowdown is that the highlighted item can popup anywhere on my screen(s). This "gaze time" adds up if you need to browse through dozens of results.

It would save me tons of time if the search results window had a preview of the result:

Search Results Preview.png

The found item should be in the center, preferably highlighted in some way.

It would allow me to give the listbox key focus, and use up\down to browse through all items very quickly, without any need to clean up!

Some additional thoughts: