LabVIEW Idea Exchange

When I was newer to LabVIEW, I found it hard to understand how people could identify front panel object styles e.g. NXG style string control vs System string control. 

I believe it is the sort of skill that takes experience and experimentation, and it only gets more complex when the appearance of the string control is customised. For example, modifying the above controls so they are the same size, they are practically identical...

I have never been able to find a good complete documentation of the differences in appearance and behaviour between different styles of front panel object - seems each style of each type of control has their quirks. So when presented with front panel objects that you did not make yourself, it is hard to 'reverse engineer' them if changes are needed. This makes it harder to learn how to make good UIs.

A potential solution would be to add a property which tells you which style a control or indicator was created as, or most recently replaced by. E.g. modern, classic, system, silver, NXG. An extension would be to add a 'reset to default style' which would behave as if replacing the customised object with an object of that style from the palette. A further extension would be to allow changing of style e.g. in this example from NXG to System via a dropdown box, although not all front panel objects are available in all styles so I can see this being more difficult to implement.

This is probably the ugliest UI mockup you will see all day but I hope it gets the idea across and sparks some conversation:

This would be accessed via 'properties' on the right click menu of the front panel object.

I'm not very experienced with XControls, QControls etc. so would welcome suggestions about how these should behave. Perhaps there is some nuance to do with styles that I am missing.

This idea is related to this one which talks about setting style for the whole front panel.

Let me know your thoughts!

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.