Selection of Items on BD or FP needs to be Easier!

[JackDunaway]

Currently, it's a crapshoot when you drag an ant trail selection box around items on your FP or BD. It's truly an art to become good at selecting objects in LabVIEW - we all learn "hot spots" to place our selection rectangles, and we all heavily rely on the "Shift+Click" method of adding or removing objects from our selection. Below is an example of what actually might be selected when dragging a selection box:

All horizontal wires were selected down to "ABCDEF", even though just a very small portion of the visible wire was inside the selection box. It's not intuitive to try to not select wire that is hidden behind the Unbundle.

I propose a method that mimics selection in some graphics editing and CAD programs: the idea of "Enclosed" and "Inclusive" selections. An Enclosed selection is made by dragging the mouse from L to R. This operation selects only the objects THAT ARE COMPLETELY ENCLOSED by the selection box, ignoring objects that are partially outside the selection (the red arrow is not part of the BD, it merely represents the motion of the cursor):

Alternatively, if you drag your mouse from RIGHT to LEFT for a selection box, you select every single object that is fully or even partially contained within the selection box:

Voila! Selection is now a TAUGHT SCIENCE instead of a LEARNED ART!

[AristosQueue (NI)]

I want to clarify something in case it comes up later... there is something like this idea that is currently "in beta" but it applies only to structure nodes . It is not exactly this idea. Anyone who sees 2016 and evaluates it might see that feature and think that we're not really implementing this idea. We are working intially with a limited subset of the idea to see how it goes. It might not survive the beta testing, depending upon feedback. Regardless, this idea will stay "in development" as we try to get it right.

[beavercreek]

Will this new selection ability do anything to ease grabbing the end of an unterminated wire?  Currently one has to aim fairly close, some wait for the autotool to switch, and then one can click.  Would be nice to drag a selection box around the end of an unterminated wire and have it get attached to the mouse.

[Darren]

Available in LabVIEW 2016 and in LabVIEW NXG 1.0. When dragging a selection box, the selection updates in real-time during the drag, giving immediate feedback as to which objects will become selected when the drag is completed.

[Disappointed_]

This is not completed. Please re-open it.

The original suggestion specifically mentioned differences for "Inclusive" and "Enclosed" selections. Updating in real-time is a nice feature, however, it is not the feature suggested here. This seems to be a trend throughout this forum; NI users marking things as completed that are simply not done. It's very frustrating to browse through here as a new user and see this rampant, along with 5 year wait periods before a response from NI. 

[AristosQueue (NI)]

@Disappointed_ The idea was explicitly evaluated. Allowing drag in different directions to select different things appeared to be confusing to enough users that we decided against it. We looked at what motivated the original request: "Currently, it's a crapshoot when you drag an ant trail selection box around items on your FP or BD." Although we did not use the solution proposed, we were able to address the problem the idea raised (and feedback from customers suggested that, yes, we had addressed the "crapshoot" problem); therefore, we marked the idea as complete. We aim to solve the problem that the idea raises more than the particular solution requested.

> This seems to be a trend throughout this forum; NI users

> marking things as completed that are simply not done. It's very

> frustrating to browse through here as a new user and see this rampant,

I'm one of the two people who are the primary gatekeepers for this exchange. I honestly believe you're wrong, but if you have specific examples, I'm happy to re-evaluate it. Perhaps you are referring to things that are marked as fixed in LabVIEW NXG? That is the new platform that is slowly but inevitably replacing the LabVIEW 20xx platform. Many of the changes asked for here are deep refactorings that were better tackled by building an entirely new platform. That new platform is accreting functionality... as it does, we are trying to address long-standing issues of LabVIEW, many of which are stated in this Idea Exchange, and marking the ideas as complete is both an acknowledgement that the problem is something we want to fix and an acknowledgement that it isn't going to be done in the LabVIEW 20xx platform.

> along with 5 year wait periods before a response from NI. 

If by "respond" you mean post on the forum, we reply to most ideas within a week or two to acknowledge them or ask questions or close out the obviously problematic ones. If by "respond" you mean implement the fixes, the long wait periods are a consequence of there simply being more customers making wide-ranging suggestions than there are developers and developer bandwidth. We work as hard as we can, trying to deliver as much improvement in every release of LabVIEW as we can pack in. I and my team wish we could do more faster; I have to hope that what we do is sufficient to retain your business.

[Disappointed_]

You said it yourself:

"Although we did not use the solution proposed" But if your goal is not to implement the solutions proposed by users and instead solve the problem in a way that suits you, that's fine, I misunderstood the purpose of this section of the forum. The description seems to suggest it's about the idea, though. 

The standard of marking things as complete when implemented in LabView or LabVIEW NXG seems contentious in its own right given that NXG doesn't support a lot of hardware. But I'm aware of that distinction. Zooming in (a very contentious issue here) on my high-res display would be wonderful when I want to select that one pixel representing a wire, but I can't upgrade to NXG because my hardware isn't supported. That issue, (if I remember correctly) was posted in 2009, garnered tonnes of kudos and was addressed by NI in 2015.

Here is a suggestion specifically regarding that trend. I can provide more examples if necessary. Perhaps the 1-2 week response is a new directive?

I'm sorry if I'm frustrated by your efforts - software development isn't easy, especially when you're dealing with code from as far back as LabVIEW's inception, but given the cost of this software for users, that should not be an issue. 

[AristosQueue (NI)]

> instead solve the problem in a way that suits you

I hope it's a way that suits our users. It doesn't do us any good to make LabVIEW for ourselves -- that won't sell! When we work an idea, we talk to users, we run betas, we do in-house evaluations, and we look at trends in other, similar software. Our goal is to improve LabVIEW and remove the barriers to productivity. Sometimes a solution that seems good when proposed doesn't turn out to be as good in practice, but if the problem is real, we look for alternate approaches.

> Perhaps the 1-2 week response is a new directive?

There's no particular directive. It's a general goal. Responding to the Exchange is completely secondary to our job to implement the software. It fits in our spare time. The only solution would be to put someone on the forum whose primary job is feedback here, but that would move the idea exchange further away from R&D. I believe there's value in having the team directly aware of the ideas as we sort through them. We do read them all. But it being a secondary job means that there's lag in response sometimes. Other times, a weak idea may not get a response at all. I try not to let it happen, but it does.

We do leave ideas in "New" for long times. We don't have an "Accepted" state because that makes it sound like we're committed to doing the idea. I've proposed something like "Sounds Reasonable", but, so far, if an idea isn't immediately Declined, leaving it as New is how we've decided to handle it unless/until that idea gets picked up for development.

It's a balancing act to keep the forum open for suggestions without overpromising to our customers. I try to monitor for frustrating posts like yours to let me know when things get imbalanced.

[Disappointed_]

Off topic things aside. (and thank you and @Darren for your efforts, @AristosQueue)

The gist of it it, in my opinion, is that this issue was not completed, it was declined, as the idea proposed in the post was not implemented. Selecting something is still a bit of a crapshoot, as users still don't really know what moving the selection box will select. They can see it now in real-time, but will still have to move the selection box to get what they want after they figure out what will be selected, at times, they may also have to move the selection box origin if they have not picked a good spot.

[AristosQueue (NI)]

That's a reasonable disagreement. It wouldn't feel right to me to close this as Declined, but perhaps a status more along the lines of "Alternative Implemented". The problem listed is a good problem and one R&D aimed to fix. The specific solution didn't appear to be so good when we tried working with it, so we did something else. We will continue to try to improve things in future versions as new ideas come in.