LabVIEW Idea Exchange

I like to collapse long string and path constants to consolidate diagrams.  Showing the string or path value in the tip strip is useful but tedious to update.

I suggest an appearance property that would automatically display the current value in a tip strip for string and path constants.

This property would be most useful if the Block Diagram Options page was also modified to allow a global setting.

I always wanted to have a table or a (Multicolumn) Listbox that allows me to integrate drop down menus (or other elements)

Here's an example from another software (Agilent Benchlink datalogger) which illustrates this quite well:

One could realize something similiar by creating his own Array of cluster, but this is cumbersome and very uncomfortable to change/maintain, mainly because of the difficult selection of all the control frames which are placed one over the other...

Functionality good, layout questionable...             Layout similar to the picture above, but not very flexible (not an array) and "hard to handle"

PROPOSAL:

Add a new type of list control, behaving similar to a Array of cluster control, where different types of already existing controls can be selected as it's elements, and where those controls are placed next to each other without those annoying and real-estate consuming spaces between them

A-T-R

I'm not sure if this idea already exists, at times i wish to have an option to display the line numbers in a string control/indicator/constant.

Wouldn't it be nice if Probes window had a drag'n'drop reorder functionality, maybe even a Sort?

Often you (I) place a couple of probes, maybe add some in another VI and then go back and add one earlier in a block diagram. 

Is this a problem? Well, it's not breaking, but i'd like probe 1 to be the earliest executed probe and so on. Often execution order can easily be something like 13, 19, 3 and drag'n'drop #3 below the #19 would the shift them as 3, 13, 19. (Similar to how Reorder Case works)

It'd be nice if you could drag this probe in the probe window and it'd change numbers accordingly (switch/reorder within the VI).

Maybe even have Sort button that simply renumbers all as they're shown in the probe window.

It's somewhat similar, but different, to Altenbachs switcheroo idea: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Probe-switcheroo/idi-p/3126138

A great time saver would be if we could drag or click to switch connections directly in the connector pane instead of having to disconnect and reconnect controls.

This can be a simple two click process:

If there's already another control\indicator where you click, they get switched.

Hi,

i propose to add a "Key Focus" event for each control. We already have Mouse events (leaving, entering) - but when the user (or the programmer) prefers the keyboard (with proper tabbing setup) you have to poll each interesting control for it's "Key Focus" property to initiate a user event...

So please:

Add a "Got Focus" (and additionally a "Lost Focus") event to the event structure!

Hi,

There are numerous ideas floating around about where the color box constant and control should be located in the palettes. How about if there wasn't a distinction between a color box and its numeric representation? Like the "View As Icon" option on terminals and clusters, I suggest a "View As Color Box" on numeric constants and controls/indicators:

I'm undecided on if this options should be available for all numeric data types, integers only, or U32 only, and what should happen to the Representation options when the numeric is a color box. I see at least these options (ordered after my preference - I prefer 1) the most):

1) The "View As Color Box" option is available for all numeric data types, but when selected the data type changes into U32. If you change Representation to anything else but U32, the "View As Color Box" option is automatically deselected.

2) The "View As Color Box" option is available only when the numeric is U32.

3) The "View As Color Box" option is available for all numeric data types, and coercion happens between the selected "color value" (U32) and the true Representation of the numeric.

Several ideas would be fixed by this, for instance this and this.

Cheers,

Steen

In line with giving us a better polymorphic VI editor, doing the same for Enums would be great.  The current implementation is SSSLLLOOOWWW and unwieldy.

Please re-visit this functionality to make our lives easier....  So many people create enums via rings for exactly this reason.  This is just unneccessary.

Currently if you flush an event queue that data is lost. Flushing and destroying and event queue should have the same interface as flushing/destroying a normal queue. Return the Data! I want the option to batch process the events, The code below would have to handle 1000 separate events to get the data out.

Idea
Flush Event Queue.vi should return remaining event data.
Destroy User Event.vi should return any unhandled events.

Whenever we create a constant (or control) on a partially connected function, we get not only the same datatype (good!), but also the same array dimensionality (often not so useful).

In the vast majority, I want do do some uniform operation on the entire array, so a scalar control or diagram constant would be much more desirable. I usually end up creating the array constant, then pulling it out of the container, hook it back up, and delete the container. This guarantees the correct datatype (I32, DBL, CDB, etc).

(It is even more tedious to place a diagram constant from the palette and then remember the datatype and adjust accordingly).

IDEA: 

When creating a control or constant, and it would result in an array, I would prefer to also have a scalar option.

This little move illustrates it in the case of creating a diagram constant. It should apply equally to controls.

I'm developing code, and like most people I know, I have multiple VI's open at once.

If I then go and open the VI properties dialog, I lose track of what VI the properties are for, especially if I get an interruption.  I know I can just close the properties window and open it again for whichever VI I wanted (or go to the parent category to see the name), but this could be solved by simply adding the name of the VI to the window title of the Properties dialog. 

like this:

.net and many other languages have an intuitive and simple way to allow you to define how a window behaves when you resize it: anchors.  Anchors allow you to define the distance between an edge of a child control and the edge of a parent control regardless of the size of the window. The size of the control itself stays constent unless it violates the rules of the defined anchors in which case it changes sizes to meet those rules. For example a front panel with the following anchors:

Would be resized into: