LabVIEW Idea Exchange

Using property nodes, it's possible to retrieve a list of subVI references within a VI's block diagram. However, there's currently no way to link each reference to its specific subVI instance.

For example, if you place three instances of subVI "A" in a diagram, you can obtain three references to these subVIs, but there is no way to determine which reference corresponds to which instance.

The proposed idea is to introduce a "This SubVI" reference — a property or node that would return the reference of the current subVI instance (the one hosting the object or node). This enhancement would significantly improve scripting capabilities, support tool development, and aid in debugging tools.

In a recent version of LabVIEW the height of Unbundle By Name and Bundle By Name elements, Local Variables and Global Variables was standardised to 16 pixels. This was a welcome improvement. (I'm fairly sure that the improvement was suggested by a LabVIEW Idea. I would have liked to link to that idea here but unfortunately I can't find it right now.)

The size of Boolean constants is currently 16 pixels (width) x 14 pixels (height). This should be standardised to 16 pixels x 16 pixels. A vertical stack of Boolean constants would better align with a stack of local variables, global variables, or UBN/BBN elements. They would also align better with the default sized LabVIEW grid (16 x 16 grid).

Thanks!

The name of the "Get Date/Time in Seconds” function is misleading. The function should be renamed.

Details

• The current name does not make it clear which Date/Time it is going to return. The words "now" or "current" are missing.
• The "In Seconds" portion is misleading and unnecessary. The function correctly returns a timestamp data type. The timestamp represents a moment in time that is expressed not just in seconds, but also using lots of other time units such as days, hours, minutes, ms, us, ns, etc. I understand that when a timestamp is converted to a DBL, the value represents the fractional number of seconds since the beginning of the epoch, but this is an implementation detail. It should not be part of the name of the function.
• “Get Date/Time in Seconds” would be a suitable name for a conversion function that takes in a formatted Date/Time string and outputs a DBL that represents the number of seconds since the beginning of the epoch.

Names of equivalent functions in other languages

• .NET: System.DateTime.Now
• C++: std::chrono::system_clock::now()
• Python: datetime.now()

Notice that the equivalent function names contain the word "now" and omit "in seconds".

Perhaps the best new name for the function would be “Get Date/Time Now”. This name would be very much in line with the .NET, C++ and Python equivalent function names. This name would earn the "let's not reinvent the wheel" prize.

Nevertheless, I would be happy with the following names too:

• “Get Timestamp Now”
• “Get Current Date/Time”
• “Get Current Timestamp”

Notes

• Changing a primitive name may break VIs that use VI scripting to find or create this node. This is a downside. I believe that in this case the long-term benefits would outweigh the relatively minor annoyance of hopefully relatively few developers having to modify those scripting VIs to use the new primitive name.

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.

When I add block diagram comments inside a structure, they are often long enough to require several lines.  Since auto-grow is on, I need to stop typing before the comment reaches the edge of the structure, resize the comment to be multi-line, select inside the comment again, and re-start typing.  From then on, the comment word wraps at  my sized width.  Could you make a special character like ctrl-, alt-, or Shift-comment move me to the next line and make the comment that wide, so it word wraps at that width from then on?  While you're at it, could a word-wrapping comment autogrow in height to fit the comment, like a one-line comment auto-grows in width?  Subdiagram comments could use that feature, too.