Jump to content

Selecting Objects


Recommended Posts

And the reason the first click point wouldn't have to be on the selected object is because selection is suppressed for as long as you hold down a certain key, let's say the Alt key. And if selection is suppressed, it's not going to look for the first object in the stack order at that point, so holding down that key also solves the original problem that prompted this thread and many others.

For 2D: that's not working: if you have the bottom object selected in a stack order, and you Alt grap-move, you'll still get the upper object.

For 3D: it's the same as for 2D objects

Link to comment
  • Replies 63
  • Created
  • Last Reply

Top Posters In This Topic

So, with David's proposed change to the 2D Reshape tool, sometimes we'd click on a surface and nothing would happen. And then we'd think, "What's wrong?" And then, "Oh, right, because that other thing behind it was already selected. I have to click somewhere else, or deselect everything first."

No, that's not how my suggested mode would work. In the example above, since you're not attempting to drag a selected object, but clicking, the top object would select as you expect. As I've said before, I'm not changing how selection occurs. merely the fact that attempting to drag a non-front object will not automatically revert to dragging a front object.

To refine the idea further, I'm suggesting that to drag a non-front 2D object, you will need to drag it by an edge or point (as would happen with 3D objects anyway). NB- the presnet situation is you are given cursor cues of edges and points of a hidden object, so you would use the cursor cues to locate where to drag the object - straightforward. This also means if you select/drag on a front filled 2D surface, it will select and drag as you expect, even if a non-front selected object is behind it - unless you are over an edge of that object, in which case you will know this because of the cursor cues (and the handles) and then the non-front object will drag.

So you will only drag the wrong object if you ignore the cursor cues.

Link to comment

I think we have almost come to an agreement here, so I'm going to summarize:

1) It is kludgy to keep the object on top selection rules currently in place. More sophistication is needed.

2) An alternative is for the selected object to trump the object on top, and drag that one. (Selection is functionally equal to on top)

3) Minor complication is when a selected object is underneath an object you want to select, grabbing the surface may be confusing.

4a) The simpliest answer to (3) is "who cares, it's more intuitive than it is now".

4b) An alt-select approach could also be used to inhibit selection. This would also give users a displacement move fuction which is sorely missing in VW currently.

4c) Perhaps the surface of an object should just follow the current rules.

Are we ready to propose this to the people who are writing the software? Please edit my list, so that we can get the feedback we need from the designers. Speaking of - is this something we can arrange, Katie?

Link to comment
No, that's not how my suggested mode would work. In the example above, since you're not attempting to drag a selected object, but clicking, the top object would select as you expect. As I've said before, I'm not changing how selection occurs. merely the fact that attempting to drag a non-front object will not automatically revert to dragging a front object.
How will the computer know you're "not attempting to drag" the object? Selection occurs as soon as you click down, before you either start a drag or release the mouse button.
Link to comment
Are we ready to propose this to the people who are writing the software?
I'm not in agreement with your list. I'm just resigned to the fact that 2D is being phased out and they're not going to do anything to improve it, and that if something helps 3D work, even at the expense of 2D, they're more likely to do that. As I said 'way up above, I assume they've already scheduled something like what David proposed.

I'm sure they considered all this stuff a long time ago and have their various opinions on it and their corporate policy. The only way this forum thread could influence that is if it showed most users favor a certain change. But, on the contrary, it shows that only a few zealots have any interest, and our opinions are divided.

Not that it isn't fun to talk about it. We think about these things as we use the software every day, and it's nice to have a forum where we can talk about an ideal VW world.

Link to comment

Oh. I'm not in the least bit interested in just talking about it. I thought we were trying to help VW out by specifically describing what we don't like and what we would like to see. I consider myself to be representative of a typical user. VW is lucky to have "zealots" like us thinking critically and posting those ideas. I'm not so sure that it has been properly thought out by the designers...

Also, I don't see divided opinions at all, simply different interpretations of the same thing for the most part.

Carry on.

Edited by Jhaceun
Link to comment
... to drag a non-front 2D object, you will need to drag it by an edge or point (as would happen with 3D objects anyway).
This might work. hmmm... first look for a selected object that has an edge at the click-down point, and if that fails, check for any object there, whether selected or not, and either edge or hatch area. Yes, that might take care of the 2D problem, if it can be done, i.e. if it doesn't conflict too much with the way the database is searched. I should have thought of that before, instead of arguing about whether 2D objects can be selected by clicking on their fill area.

Of course, it still does nothing about moving by remote displacement points. But you say 3D work has no use for that. That surprises me. In Sketchup3D, I use that a lot. A thing is this far from a column, and I want to move it or copy it to the same position relative to another column. But VW 3D isn't like that at all?

Link to comment

We could go at this from a different angle....how about the tool stays more or less as is, and we have 'Save Stacking Order' and 'Restore Stacking Order' menu commands. Photoshop has a lot of 'Save-able' and 'Loadable' settings.

I'm very stacking order dependant.

Link to comment

Probably more cumbersome for the most part.

One of the other work-arounds when you're having trouble grabbing an underlying object is to send the one in front to the back, but of course that messes up the stack.

I'm very often working with more than two or three underlying objects. You'd save the stack, do whatever you want to get at whatever you need to get at, and then restore the stack to get things looking the way they were.

Maybe it's a fairly useless idea...

Link to comment
But you say 3D work has no use for that.

No, I didn't say that - I said "... it would be OK, but I've never felt the need for it."

I also said "your vector move function would have enough support to warrant it anyway, so as I've said before there is an argument for having both new modes."

In other words it should be included, because a lot of other want it, and despite the fact I don't feel disadvantaged by not having it, I'm open to the possiblity that it would be useful for me as well.

Since I seem to have finally explained to your satisfaction how my suggested new mode would work, then why not agree that both this and your "selection de-select" toggle have their own particular use and should both be included in a revamp?

Link to comment
....how about the tool stays more or less as is, and we have 'Save Stacking Order' and 'Restore Stacking Order' menu commands.I'm very stacking order dependant.

One of the main arguments of my suggested selection tool mode is the pure logic of dragging the selected object, not the front (unselected) object. However the issue remains as how to best select an object that is non-front or "hidden". Sometimes often there is a handy unique edge you can click on, but sometimes not.

I've previously suggested a solution which works similar to that used in InDesign: You hold down the cmd key (or another key) when you click on an object; each successive click selects a different object in the stack. In other words the stack order cycles through and each object is temporarily brought to the front. When you release the key, the last object remains selected, but the sacking order reverts to what it was originally. Now with the new "drag selected object mode", you can drag the object even though it remains behind something else.

This is much better that the current work-around of bringing objects to to the front, thereby constantly re-arranging and confusing the stack order. It's a very simple and efficient method.

I hope this suggestion also explains why I have been arguing so strongly for the drag selected object mode, because the temporary stack cycling method would have little use if you still couldn't drag the selected object. The two work very well together.

Link to comment
Since I seem to have finally explained to your satisfaction how my suggested new mode would work, then why not agree that both this and your "selection de-select" toggle have their own particular use and should both be included in a revamp?
Yes, as I said above, the idea that, when you click down to select, any screen-hinted edges/handles of already-selected objects should take precedence over edges/handles/fills of unselected objects (even overlying unselected objects) -- that idea might work without messing anything else up, and if so I'm all for it. I don't even see why it would need to be a separate mode. Maybe the 2D Select tool should just work that way all the time.

But as for the idea of a modifier key to temporarily suppress selection: I think making it a toggle switch would be a bad idea. It should be a momentary switch, the same way the Shift and Ctrl keys now modify the 2D Select tool. No selection would take place while it's held down. So you'd only need to hold it down at the moment you start a drag-move.

I'm very often working with more than two or three underlying objects.
I know how frustrating it can be trying to maintain stack order, not only because of selecting and moving as you mentioned, but because things go to the front when you Group them or Add Surface. There are often unpleasant surprises on the print-out.

Do you ever use Layers to control visibility? Put everything that needs to be in front or behind something else on a separate layer, and just stack the layers to get the visibility you want?

Link to comment

Do you ever use Layers to control visibility? Put everything that needs to be in front or behind something else on a separate layer, and just stack the layers to get the visibility you want?

I have used that approach, but for most of my work I have other requirements for the use of my layers that makes this much more complicated than just working with things the way they are, which for the most part works well enough. It's just the occasional situation that ties me up a bit.

It seems to me that the change you suggest where selected objects take precedence would be a huge improvement, and might easily be implemented. It's possible, of course, that it could create some unforeseen problems in other situations, but I think this should be wish-listed.

I think I'm done.

Charles

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...