LabVIEW Idea Exchange

The new debug window in LabVIEW 2025 Q3 automatically expands arrays to show all elements across multiple lines. While this full view can be helpful, it often becomes disruptive during debugging.

I have attached a video that shows a side-by-side comparison. The left side is LabVIEW 2025 Q3, and the right side is LabVIEW 2024 Q3.

As you can see, when an array contains many elements, the new multi-line display consumes a large amount of vertical space on the block diagram. This pushes other probes and data displays down, causing their positions to shift and making it difficult to monitor them. There are many cases where I only need to see that the array contains data, not every single element, and I would prefer the more compact, single-line view.

I propose adding a feature to allow users to select the display mode for arrays in the debug window. It would be ideal to have a toggle or option to switch between the new multi-line view and the classic single-line view, similar to how it worked in LabVIEW 2024 Q3 and older versions.

This would provide the flexibility to choose the most appropriate view for the situation, greatly improving the debugging workflow and the visibility of other data on the diagram.

What is a strictly-typed reference?

A strictly-typed reference is a kind of reference whose type descriptor contains an inner, user-specified data type.

For example, a queue is a strictly-typed reference because it contains the data type for its elements, specified when creating the queue.

Here is a non-exhaustive list of such reference types:

 - Queue

 - Notifier

 - User event

 - DVR

 - Datalog file reference

 - Strictly-typed control refnum

 - Strictly-typed VI refnum

 - Shared variable

 - Network stream (reader/writer)

 - RT FIFO

 - FPGA IO / register / memory / FIFO / handshake

 - ...

Idea:

Add a new primitive that would output the inner data type of any strictly-typed reference.

Here is a design example of the primitive, which could be named "Get Contained Data Type of Strictly-Typed Reference":

It would work for all the strictly-typed references mentioned above.

Motivations:

The implementation of malleable VIs is sometimes limited (or made complicated) by the fact that we miss some basic "type operators", such as getting the contained data type of a strictly-typed reference. While this missing function could be implemented using some tricks for most strictly-typed reference types, it is for example impossible for user events (See this thread for more details).

Typical application:

A malleable VI that takes a user event (for its type) and outputs a newly created refnum with the same contained data type:

This simple code is currently impossible in the general case due to the nature of user events.

Remarks:

1. The output terminal of this primitive will have to be named exactly as the contained data type, which is crucial for user events.

2. The output would have the LabVIEW default value for the data type (False for booleans, 0 for numerics, "" for strings, ...).

3. The primitive could be placed in a dedicated "Malleable VI Tools" palette.

4. In case the FPGA-specific implementation creates a dependency to the FPGA module, we could have a separate primitive just for FPGA (and also for RT if required).

What do you think?

Regards,

Raphaël.

It would be great if one could mark certain files as having an absolute path so that it is easier to move projects that use a common resource around in a multi developer/station environment.    

A project might for example require a shared library or file that is installed by another application into c:\XXXX

Currently, all developers must place their project at the same relative folder depth to the shared resource to avoid linking issues.  e.g If Developer A uses c:\Users\Dev A\Project\  then Developer B would need to use  c:\Users\Dev B\Project\..   The project would complain about not finding the shared resource if Dev B was to use  c:\Users\Dev B\Repos\Project instead for example.

Marking the shared files as having an absolute path would resolve this