LabVIEW Idea Exchange

Problem

I find myself wanting to Ctrl+Drag to add/remove diagram space INSIDE of a structure without actually resizing the structure itself AND without modifying any other frames – I just want to clean up the visible diagram that I am working on.

However, this is not how LabVIEW currently works – the structure itself is also resized, and the space within other frames of the structure are resized as well (outward/inward from the same point as the Ctrl+Drag action), which can mess up both the code in other frames as well as the code outside the structure.

Proposed Solutions

Option 1: Lock Structure Size Add the ability to lock the size of structures (or perhaps only lock them from growing during creating/removing space), so that I can use Ctrl+Drag to create/remove space without impacting the structure and the code around it. This would be similar to "Auto Grow" but would perhaps be an "Allow Grow" or "Lock Size" setting.

Option 2: Modifier Key Use the Shift modifier during Ctrl+Drag and Ctrl+Alt+Drag to NOT resize the containing structure. This would maintain backward compatibility while adding the new functionality.

Why This Matters

When working on complex VIs with multiple frames in structures, it's frustrating to have simple diagram space cleanup operations affect the entire structure and surrounding code. This feature would allow developers to better organize/tidy the code within individual frames without the ripple effect of resizing everything (in other frames and outside the structure).

Currently each error in terminal contains the following description: "<B>error in</B> can accept error information wired from VIs previously called. Use this information to decide if any functionality should be bypassed in the event of errors from other VIs. Right-click the <B>error in</B> control on the front panel and select <B>Explain Error</B> or <B>Explain Warning</B> from the shortcut menu for more information about the error." This occupies 367 characters (bytes).

Currently each error out terminal contains the following description: "<B>error out</B> passes error or warning information out of a VI to be used by other VIs. Right-click the <B>error out</B> indicator on the front panel and select <B>Explain Error</B> or <B>Explain Warning</B> from the shortcut menu for more information about the error." This occupies 271 characters (bytes).

This applies to terminals of all styles: Classic, Modern, Silver, Fuse Design System.

This adds a total of 638 characters (0.62 KB) to each and every VI that uses a pair of error in/out terminals, which is probably a majority of VIs in LabVIEW.

The descriptions appear in the Context Help window and can be useful to beginners. But this benefit is not worth 638 bytes of space in so many VIs. The contents of the descriptions should be mentioned in training material such as LabVIEW Core 1 or the LabVIEW Help.

This proposal is to remove (clear) the error in and error out descriptions, such that VIs are "slimmer" and codebases are smaller.

Current Behavior of LabVIEW
Currently, the error messages that emerge from bad call to a Property Node or Invoke Node only state that the error occurred in a property node or invoke node.

User Need

As a user of LabVIEW, it saves me considerable time in development/debugging, when I can precisely know why and where in the code an error occurred , so that I can get on with the actual work of fixing the bug in my own code/logic.

Problem For Users 

The current behavior, described above, makes it impossible to know (without placing probes and retaining wire values):

A) Which Property Node or Invoke Node actually generated the error (in cases where there are many of such nodes)? Again, all we know is that some Property/Invoke Node on the block diagram of the VI raised the error.

B) Which specific Property actually caused the error, in cases where a Property Node has multiple properties that it is reading and/or writing.  Again, all we know is that the error occurred inside a Property Node.

Proposed Solution

Error message for invoke/property nodes should state:

- the Name of the Method or Property where the error occurred
- the Class Name of the VI Server Object (if available)

- the Object Refnum value (e.g. the hex value of the object reference)

- possibly even (only if running in the editor and not the runtime environment) the VI Server Scripting UID of the GObject node on the Block Diagram for super-fast debugging with a "fancy error dialog of the future" (TM) whose LV Idea Exchange post with undoubtedly be coming soon...

Existing right click menu during wiring provides options to create terminals or wire branches.   Proposing a feature to add a cluster unbundle terminal when wiring clusters, that places and wires the terminal with the desired element reference.

Starting from LV 2023 Q1, the terminals height of some nodes was harmonized to 16 pixels to improve diagram readability by reducing the amount of needed wire bends.

Some candidates for this harmonization were omitted though:

 - Data nodes of timed structures (timed loop, timed sequence).

 - I think pretty much all of FPGA nodes (IO nodes / methods / properties, FIFO / memory / register / handshake methods, IP integration, high-troughput math nodes, ...).

Example with a Timed Loop:

The idea is to also allow RT and FPGA developments to benefit from this harmonization.

A very common task when operating with 2D pictures are mouse down/move events where we are interested which pixel was just clicked. While there is an event data node for the clicked coordinates these are relative to the front panel and translating them into image pixel coordinates is a chore and requires jumping through flaming hoops tweaks. (i.e. label yes/no? zoom factor? etc.)

However, there is a "Mouse" property for 2D images that has all the information directly in pixel coordinates and mouse button states. Currently, we need to read that property inside the mouse event to easily get the information we always (always!!!) want in such an event!

It would be cleaner if mouse events on pictures would output these mouse properties directly as an additional event data node.

Two clear advantages:

• Cleaner code for those who know how to work with this property.
• Stop sending newbies on a snipe hunt trying to figure out how to translate the current "coords" event data node into something useful for the intended task.

Here is an example where this idea would have helped

Here's a picture for the graphical thinkers!

Thanks for voting!