LabVIEW Idea Exchange

Make the Panel Resize event in the event structure a filter event.  This would allow for clean, professional looking control of VI panel size.  Use cases include: limiting the maximum panel size, preventing a panel from resizing in one direction, only allowing the panel to resize in discrete increments, etc.

In traditional windows programming, filtering the WM_RESIZE event is often used to control window size and I'd like to see this same functionality come to LabVIEW.

Ideally, this change would include a Discard? option as well as NewBnds and Act as options in the Event Filter Node.  Setting NewBnds or Act would allow the programmer to amend the resize before it takes effect.

Originally discussed here, this would be a time saver in quite a  few cases:

when dropping a structure (sequence, case, while or for loop, etc) over wires, an option should be provided allowing these wires to go through the structure (instead of ending up untouched UNDER the structure as is currently the case). Maybe with a modifier key?

Illustration:

Starting from this simple situation, where I want to do some comparison on the two strings (please imagine that the wires go through a lot of hooplahoops rather than directly to the indicators shown, as otherwise the solution is trivial):

I currently need to drop a sequence structure and do all the connection manually before creating a subVI (or doing stuff in a case structure, see below):

The suggestion is to go directly to this:

The reasons this would be useful are plenty, I think.

For instance, you want to do some sanity check on a bunch of wires now that you have added a new control on your panel. As of today, you need to drop a case structure, get wires you are interested in one at a time, connect them to the left of the structure, pass through the structure, connect them to the right of the structure, delete the wire underneath the structure, reconnect them to the right tunnels, etc...

Now, for a case structure, there might be some options on how to do that (for instance connect the wires through all cases? through the True case only?). Likewise for a while/for loop (you could autoindex at the entrance and/or at the exit, a mess that already exists anyhow).

My 2 cts.

I frequently perform operations on Maps of Objects which hold private data where I do not intend to alter the structure of the Map.

Existing Solution

However, Maps are a bit clunky to work with when operating on all Elements. You must first get the list of all Keys, then use an In Place Element Structure within a For Loop and Shift Registers to operate on each Element as follows:

Potential issues with this:

1. Unnecessary branch of the Map which may not be optimized by the compiler
2. Excessive block diagram editing which slows down the development time involved when working with Maps
3. Potential for syntactical errors due to complexity of this operation

Proposed Solution

It would be great if there were some kind of auto-associating tunnel available to For Loops:

Note that the Key is not modifiable, nor is it even available within the For Loop.

Perhaps the tunnel icons must be changed so they are not confused with shift registers.  I just copied the association icon from the map datatype icons.

This level of functionality is similar to the syntactical abbreviations available in most languages which support maps as a standard data type.  I originally wanted this kind of functionality for Sets as well, however modifying the values may result in structural changes to the set itself due to the uniqueness constraint.  As such, this is only applicable to Map Values within For Loops.

It may not be obvious, but this kind of tunnel would not be available to While loops.

Selection

This option would be available on the block diagram through the context menu items of the Map datatype Input Tunnel to the For Loop.