LabVIEW Idea Exchange

The smaller footprint of the Local Variables in 2010 has increased usability of the IDE and readability of the LabVIEW language. Another node that could benefit from a smaller footprint is the User Event Ref Constant.

Below is some conceptual artwork on what a smaller footprint might look like. Feel free to post more concepts!

Notes

• Replacing a node via Right-click >> Replace >> selecting item from palette results in the same outcome as replacing via QuickDrop. This idea should apply to both replacement methods.
• Replacing a VI via either QuickDrop or right-click behaves correctly. The new VI label is visible only if the old VI's label was visible. In effect, the new VI retains the "Label >> Visible" setting of the VI that was replaced, which is desirable.
• This idea is somewhat related to the following idea: "Show node names when dropped" option

Many of us using graphical programming for scientific applications, where we dealing with numbers, measurements, etc.

How often we grab to Windows Calculator to compute simple equations?

What about ability to enter something like 3,75*2,8 into any constant or control (in principle everywhere where we can put numbers) and then get computation result in this place:

In the past I've worked in desktop publishing industry and using the software called "Macromedia Freehand MX", and that was really "killer feature", which saves huge amount of time.

This is how it works:

Or for example, 5 rotated copies:

Even in Color mixer simple computations are allowed:

Everywhere where I can put some numbers, in any dialog:

So, my suggestion to have the same in every numeric control or constant.

This is what I mean:

So, it should be allowed to enter here something like "3*5" or "42+3*5" 

As MVP suggested to have the only (at least) base operations *, /, +, -, also combined as shown above, but may be "advanced" support (like fully offered by Formula String) is also not so bad, why not:

Anyway it should work everywhere, including constants on the Block Diagrams:

Also, for example, on Resize Objects Dialog:

Or even in the Settings (in general everywhere for any numeric field across whole LabVIEW):

And also in Run-Time, of course, not only in Development Environment.

If you think that "always enabled" feature will be annoying, then I can suggest to make this optionally per Control/Constant Option:

Or may be as global setting in the Options.

Currently, when you right-click -> "Make Type Def" on a control / constant in a library VI, the new unnamed type definition is created outside

the library.

Also, it has the default control icon: 

instead of a library control icon:       

This leads to 3 additional tasks:

1. Drag and drop the control inside the library from the project explorer.

2. Edit the control icon to make it have the library control icon (with the horizontal slider glyph).

This is annoying because you need to copy it from another library control icon.

3. Go to the library properties and make "Apply Icon To VIs".

Bonus bug: If your new type contains a library-private subtype, the new control magically disappears from the project explorer when you click on it.

In comparison, the "Create SubVI" function works perfectly inside a library, i.e. it creates a VI inside the library and with the icon banner.

I think the "Make Type Def" function should behave the same to make library development more coherent and intuitive.

The LabVIEW compiler currently appears to use one core of a multi-core processor.  It would be nice if it fully utilized multiple cores to speed building of large projects, and recompilation of VIs when editing/opening source code.