LabVIEW Idea Exchange

Hello all,

I find myself constantly tweaking my wire labels so that they look like they are exactly vertically centered on the wire, rather than a couple pixels higher or lower.  They are not always created that way, and of course when you move the wire around they don't stay that way like I wish they would.

I'd like to propose an option to have LabVIEW automatically force wire labels to stay vertically centered on the wire (similar to other "snap-to" label positionings).  I know that other programmers prefer other positions, such as immediately above the wire, therefore having it snap to that position would be another option.  I'm not sure if it makes more sense to select one position that it always snaps to, or have it snap to one of a few options (like labels on controls do now).  I always use them consistently in the one vertical position, myself.

It may make sense to have the default be free-positioning as it stands today, but it would save me a non-trivial amount of time to have the option for it to be always enforced to what I think looks nice.    Hopefully I'm not the only one!

Obligatory pictures:

Initial vertical position when I select to make the wire label visible (looks terrible!):

The vertical position I always want it to stay in:

An alternative snap-to vertical position:

I suppose this is a grey area between feature and CAR, but it is certainly a long-standing aspect of the LabVIEW editor that vexes me on a daily basis that could be improved.

The issue is that if you are dragging to select objects on the block diagram or front panel and you accidentally move the mouse cursor to the edge of the window, LabVIEW starts scrolling insanely fast in the direction of the mouse. By the time you've figured out what's happening and released the mouse, you're often 4-5 screen lenghts away the actual content of the diagram, and you must now manually scroll back to the main area. To make things worse, you're not really sure where the origin is anymore, so it takes a little blind searching to find the screen contents again. In addition, you're likely left with a selection that is not what you intended, meaning you have to start over (more carefully) from scratch.

I really don't see any reason to scroll the panel so terribly fast. At all. A slow, steady scroll, in my opinion, would always be preferable, since the fast scroll leaves the user no real control at all over what's being selected. If anyone really wants a chaotic super-fast scrolling operation to be preserved, I would perhaps accept a shift-drag option to enable this.

Looking at all my body of work, I use tables exclusively as indicators. They are well suited to display formatted results in tabular form, but much less suited for user input, because they only allow strings. If we need to enter numbers, there is no input validation (as we have e.g. for numeric controls), so they are pretty useless for that.

It is thus a bit confusing that the tables in the palettes currently exist as controls. In fact, the modern, classic and system tables are even labeled "Table Control" (seems redundant!), while "Table" alone would have been sufficient (this has already been corrected for the silver controls :)).

It would be much more appropriate if tables are indicators by default. We can always change them to controls in the rare case where this is needed.

1. I suggest that the various table controls in the palettes be changed to indicators.
2. Their default name should just be "Table".