Jump to content

manipulate selected vs in front - please just fix this!


Recommended Posts

I've brought this up in the past, and I'm going to bring it up again.

It's very simple. If an object is already selected and I click to move or drag it - I do not want to select the object that happens to be in front of it.

In other words a selected object should override the one in front.

Oh - and please fix it in 2008 - I still feel like we just bought it and we can't spend thousands every year when a new release comes out.

Link to comment

I'll try to start using the move tool instead. and see how that works out.

I can't see one reason that it should work the way it does. Explain to me why one would ever want to move or resize the object in front instead of the one that is already selected. If you want it to work the way it does now - all you would have to do is NOT have the object you don't want selected.

I am honestly confused as to what you think would not work if this was changed.

Link to comment

Well, I'll have to keep playing around with it. It does seem to select based on which object the cursor is actually over regardless of front/back/selected, which is intuitive enough.

Although the object position description (top center for example) may or may not be the position and object you end up manipulating when you click.

There are times that come up that it is very unintuitive. Maybe it'll come up today and I can describe the exact situation.

Link to comment
  • 1 month later...

It is very hit or miss with this. I use this program in 2D only and am not involved with architecture at all. So I may use this program in different ways than a lot of people.

I do this many times a day and end up grabbing (and deselecting what I had perhaps carefully chosen) the wrong object. The resize tool would never grab another object other than what was selected.

It's not even what is in front vs behind. It is more of which object is closer to the cursor when you click, and that ends up being based on zoom factor. It's not very predictable.

I would love to see this fixed. It works fine with the resize tool - make it do the same with the move (crosshair) tool! Why do the VW programmers think they know better than me what object I want? - I want the one SELECTED!!!

Link to comment

I sometimes have this problem.

And I agree that if I have gone to the trouble to select something, then the next action I undertake should operate on the selected object.

The problem is that this is a dual purpose tool, and the computer doesn't know if I want to drag the selected object, or change the selection.

I select an object by clicking on a portion that doesn't underly another object, and then try to drag it by a point that does underlay another object. As a 'selection first' tool, it assumes that I want to change the selection to the overlying object.

If it didn't assume this, then how would I change the selection?

Deselect everything by clicking in an open space first....perhaps.

Link to comment

You're right, there is a conflict with this dual purpose tool, but here's an easy solution:

The tool should not be able to select an object when it is active on a selected objects snap point. Done.

Only in the case of two snap points over each-other would the select tool not select. It doesn't work anyway to try and select an object using an overlapping point with another object already selected - so you would lose nothing, and get rid of this bug.

Link to comment

I would agree with all the points on this thread. Yes, the selection tool as it is may not appear broken. However, it is unintuitive in its current employment. I have run into this time and time again, where I select an object with the intention to move it, and with my next click, some other nearby object is selected and then the software moves that object instead.

That result is unintuitive because the software has already taught the user that the selection tool is used to move an object.

So the solution is to use the move tool. That's fine, but the move tool has no selection functionality, and it should to be an intuitive tool. It also means that the user is expected to remember all the conditions where another object may be on top of an "intended" object and also remember that he/she must use a different tool than the one that is already known. This ignores the power of the computer tracking data for a given object.

This unintuitive process, which seems to be a theme in VW, is that unique situations all require unique tools and mini-workflows even if the core functionality (or purpose) of the situation is very similar to a common one, such as the situation this thread is based on. This adds to the complexity of the software as well as the learning and use process.

The functionality of the common tools, commands and functions should set the paradigm of use for similarly functioning actions. It's sad to me that VW doesn't employ this basic usability guideline.

Either the selection tool should employ JBender suggestion of not engaging any other object when the tool is active on a selected object, or add selection capability to the Move tool (perhaps via a keyboard command that temporarily allows selection while held down).

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...