Much Easier Cluster and Array Selection

[Darin.K]

There seems to be little doubt that selecting objects using the old selection rectangle is a "crapshoot" at best.  While I probably won't complain too loudly if that idea is implemented (250+ Kudos, seems plausible), I will suggest a much more modest solution to a very vexing problem for me.

Instead of new rules for selection (right to left versus left to right), I propose that LV consistently follow the existing rules.  In particular, the selection of Clusters and Arrays seems to deviate from the norm in a very annoying fashion.  If I clip just a single pixel of a control with the selection rectangle, I have selected the control.  Workable, fairly easy to swipe and select.  Now with a Cluster, for example, if I MISS just a single pixel I end up selecting the contained controls and not the cluster itself.  You get the idea, I select, grab, move, then drop only to discover that I have emptied the cluster or array which sits there mocking me. 

My proposal is that selecting a portion of a cluster or array be treated the same as every other control or decoration and select the entire object.

[tst]

I agree with Darin's feelings on this (and note that he only said clusters and arrays, for good reason) - while it is true that if this change is made you would lose the option to drag select multiple items, I'm pretty sure that most of the time I want to select the entire array or cluster and when I don't, I can shift select multiple elements.

It also happens quite often (especially on the BD) that I drag select and fail to do so correctly to a cluster and then moving the code causes the cluster to explode. Easily undoable, but annoying none the less.

[elset191]

I do the same thing with loops all the time, where I'll try and select the loop by click dragging, but miss all the borders.  Then of course, when I am moving the stuff, it just stretches the loops rather than moving them. 

[Dragis]

i run into this same quirk on a day to day basis as well. the way many development tools i use solve this issue is by using multiple clicks to dig into a container like a cluster. the first click anywhere on or in the container selects the entire container. clicking again will select the next level item under the click location, which may be another container. continuing to click will dig deeper and deeper. since most hiearchies i use are just a couple levels, it works well. when it's more than that, a shortcut (perhaps ctrl-click) can go directly to the element under the mouse.

[GregR]

Going down the road of multiple selection tools is an entirely different thing. I know there are long time users that still disable the autotool, but overall I think it has really helped usability for the vast majority of our users. Anything that moves us back toward explicit tool selection is going to have significant hurdles.

I brought up the issue of consistency largely because part of the original idea proposed "LV consistently follow the existing rules". I assumed that meant consistency was favored. I agree that the selection of items inside and outside a container is much more common for the diagram and for tab controls. It is less common in clusters and rare in arrays. So the question is which wins out? Is it better for containers to be inconsistent with themselves to better match expected usage?

As for a concrete example, I mentioned doing a drag select to align a control inside a tab with a control outside the tab. This use case can also apply to aligning things inside a cluster with things outside the cluster. For 2 controls shift click is easy. If there are multiple controls both inside and out, then the drag select is the natural operation. Another issue I have run into is trying to select multiple controls inside a cluster where there is no empty space inside the cluster to start the drag. In this case I will start the drag outside the cluster simply so I can find a spot to click. In general I think this idea would hurt usability of selecting multiple controls inside a cluster. That could still mean the change is warranted.

[Darin.K]

Multiple selection tools can easily fit into the autotool, but that is more of a distraction right now.  An interesting and important one down the road, but for this idea let me sum up my thoughts.

1.  This particular idea is for Clusters and Arrays only, not tabs, not diagrams.  The use of clusters as UI elements may be convenient, but is not their fundamental purpose.  They are datatypes with controls, indicators, constants, etc., like all other controls.  Tabs are for UI purposes only, they are strictly containers, their datatype does not reflect their contents.  They can be treated differently as far as I am concerned.

2.  You are sacrificing consistency amongst datatype controls to enable a process (multiple selection inside a cluster) which I feel belongs in the control editor anyway.  You are using a cluster after all, you should be Type Def'ing it.  Perhaps inside the control editor you can keep the current behavior.

3.  As a bit of a thought experiment compare the path you must take to shift-select multiple controls versus drag-select.  Almost identical, you just have to click a few times along the way in the first case.  Now compare the path you must take to clip the border of a cluster to select it versus enclosing the entire control/constant.  Potentially a huge win.  You can shift-click the cluster itself, but try finding that 1-pixel sweet spot a few times on a laptop.

[GregR]

You definitely have valid points and I'll even throw in an extra one for you. There is already an example of a container control in LabVIEW that works the way you suggest. Many types of refnums can contain a control (datalog, queue, notifier, user event and control refnums). These do select the entire control any time the selection rectangle touches them at all. This is very similar to the array case.

Personally I'm still on the fence about the cluster, but that is why this is a public forum. Get enough kudos and my opinion doesn't matter.