JBender Posted January 28, 2009 Share Posted January 28, 2009 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. Quote Link to comment
islandmon Posted January 29, 2009 Share Posted January 29, 2009 Or move the object to the front ... Quote Link to comment
Ray Libby Posted January 29, 2009 Share Posted January 29, 2009 I don't think a fix is in order, it's not broken. This is the way it works and I think your solution would cause more problems than it cures. Quote Link to comment
panta rhei Posted January 29, 2009 Share Posted January 29, 2009 A good reason to start to use the Move tool (or whatever it is called), which is, despite some bad user interface decisions, much more powerful. Not as good as the one I've created, of course. Quote Link to comment
JBender Posted January 29, 2009 Author Share Posted January 29, 2009 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. Quote Link to comment
JBender Posted January 29, 2009 Author Share Posted January 29, 2009 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. Quote Link to comment
JBender Posted March 10, 2009 Author Share Posted March 10, 2009 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!!! Quote Link to comment
panta rhei Posted March 10, 2009 Share Posted March 10, 2009 You don't say... This is one of my biggest frustrations. Quote Link to comment
ccroft Posted March 11, 2009 Share Posted March 11, 2009 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. Quote Link to comment
JBender Posted March 12, 2009 Author Share Posted March 12, 2009 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. Quote Link to comment
JBender Posted March 20, 2009 Author Share Posted March 20, 2009 I think I'll bump this whenever this bug bugs me. Bump! Quote Link to comment
mr. iagea Posted March 20, 2009 Share Posted March 20, 2009 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). Quote Link to comment
Recommended Posts
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.