Selecting Objects

[DBLand]

I have terrible trouble selecting and moving objects sometimes. It seems to be with a solid object above other solid objects (in 2 d). I can select it but VW won't let me ever get the little cross that allow me to move the object.

It seems that VW will always prefer to move an unrelated background object rather than the selected one.

Any tips here? I could work in 'active only class' but sometimes they are the same class and any how, ts painful to do this every time when I've clearly selected it.

[Guest]

When you select it and go to move it, grab it by the line and drag rather than by the surface.

Is it a 2D or 3D object?

[jeffroyer]

I would highly recommend getting a plugin called Vectormove from this website:

http://www.vectorbits.com/

It is a fabulous tool and eliminates the types of problems you are having.

[DDDesign]

DBLand, the object get that gets moved is the one "in front" - ie not physically the top object but the front with reference to what is drawn on the layer. The last drawn object is always at the front. An alternative method is to modify>send>send object to front to make it the front object, then it is the one that will move when you drag it.

Katie, grabbing by the line is often not very convenient if you want to align or snap to a point. Id have to move an object away from it's overlapping position, let it go, then grab it again by a point and then move it back. Very fiddly! I've commented before that this is a bit inconsistent with the resize function which works (thankfully) on the selected object, not the front object. It would be a boon if the select tool could be improved. I'd suggest a change to the selection tool so that if you drag a non selected object, the front object moves; and if you select first, then drag, the selected object moves. I think this would go part-way toward solving the issue. In the meantime I'll probably have to go for the Vectormove option.

[panthony]

Select the object...

ctrl-F = move to front

ctrl-B = move to back

ctrl-alt-F = move to the front by steps of entities placed

ctrl-alt-B = move to the back by steps of entities placed

Pete

[Guest]

My post wasn't a definitive step, but more of a testing lets-see-what-happens if you try this kind of post.

[Gerrit]

DBLand, I'm aware of your problem. Here's a few tips that might help :

- while approaching the target point of your selected object, try to do this from above the object itself (so not while hovering your cursor over adjacent objects).

- sometimes it helps to first deselect the object you want to move.

[DBLand]

It wasn't a beginners question. It was a 'do I really have to make 4 clicks to do what could take 1 click' question.

I have discovered the 'work arounds' ie. 1. drag to the side away from all other objects and reselect the point you want. 2. Select object/ send to front. Doesn't always work unless select other layers is off.

DDdesign is right. Once an object is selected Vectorworks is told which object the smart points should be referencing. It just doesn't listen and chooses an object based on the object order.

When you are using unfilled polygons or poly lines this is counterintuitive.

Just wondered if there was a better way. I'll follow up the link to Vectormove. Thanks all.

[P Retondo]

DB, I wasn't aware that selecting an object confined smart cursor cues and dragging to that object. It's actually a pretty good idea, and should be added to the wish list.

As far as stretching is concerned, yes, the selected object is the one affected when using the resize cursor. But with dragging the object, no - the foreground object is the one affected.

There may be some issue associated with confining resizing and dragging both to a selected object, but I can't think of one right now. For consistency, the program should behave as DB suggests. Subtle changes like this in the way VW operates can make a huge difference in everyday workflow.

[jan15]

It's a shame there isn't a key that momentarily turns off the 2D Selection tool's ability to select/de-select objects, so that its many other functions can be used without unintended changes to the selection set.

[islandmon]

This post points to the fundamental VW programming concept of Handle >

In order to perform any function an ObjectHandle must first be established by the User.

Lack of a Handle to the Object results in 'null' .

As subsequent post note, there are numerous ways to secure the requisite ObjectHandle.

[jan15]

To turn off the ability to change the selection set, you would just have to limit the selectable object handles to those in the current selection set. Just as you sometimes limit selectable handles to those in the current layer, group, or class. A piece of cake.

[DDDesign]

Jan15, your method would work fine, appears easy to implement and it would be a lot better than the current difficulty and work-arounds. However, a selection suppression mode is really just compensation for what is a logical flaw in the existing tool. If you've selected something, and then you try to drag it, why should the tool revert to dragging the frontmost object? It defies what seems to me a clear intent to do otherwise.

Your selection suppression mode would still work, but in practice I think that you would invoke it only when you specifically need it - when the required object is not the front object. The problem is often you don't know this until you discover you've already (annoyingly) dragged the wrong object.

I still think the best solution is to have the object that is dragged being the object that has previously been selected, not the front object. This rule works perfectly well for the resize mode of the select tool, it must surely be a better method than the current one. And it would make the tool more consistent anyway.

But I guess there's nothing to say you couldn't have a selection suppression mode as you've suggested as well, just as having a toggle key for the resize mode would also be useful.

[Ray Libby]

If by resize mode you mean interactive scaling, the "u" key will toggle it on and off.

[DDDesign]

Ah, yes. I hoped there might be a key. Couldn't find a reference to it in the manual. Thanks.

[jan15]

David, the status quo is not a flaw. It's great that the Select tool normally selects and moves all in the same click-drag. Grab 'n go. It saves time on the most commonly used operation.

[DDDesign]

Jan15, I haven't suggested any change to this - refer to my post 6/27. With my suggestion grab'n go would work exactly the same.

To summarize:

1. Click/drag on object = front object is selected and is dragged. (ie grab'n go as present)

2. Click on object = Object is selected (as present)

once object is selected:

2a. Drag handle of selected object with select tool in resize mode (interactive scaling) = SELECTED object resizes (as present)

2b. Drag handle or edge of selected object with select tool in select/drag mode = SELECTED object is dragged (NOT front object as present)

It's only mode 2b I'm suggesting the change which i believe will make the select tool more convenient, logical and consistent. Perhaps set the new system up as a preference for anyone who doesn't want/need the change.

[jan15]

Well, maybe the Select tool could check the selection set first, and then check the rest of the database only if it fails to find a handle there.

But what if you want to select a solid surface that's on top of something in the selection set? In that case, you would expect to be able to click anywhere on the overlying solid and get it, not get the pre-selected object hidden behind it.

[DDDesign]

I can't see why you would expect that at all. It doesn't work like that at the moment, and I don't think it should. At the moment you can't click anywhere on an overlying solid and select it - you can only select it by clicking on an edge or vertex. If there is more than one edge or vertex, then the front object is selected, regardless of what has been pre-selected or not. I'm not proposing to change that, and I'm not proposing to change anything to do with so selection hierarchy. It's not ideal, but unless you are trying to select a coincident exact duplicate there is usually a unique edge or vertex by which the object can be selected. (Although I do like the system of cmd-clicking that cycles throught the stack eg as used in InDesign). And if you are going to drag an object, I'd always drag it by an edge, or preferably a vertex anyway, not just anywhere, otherwise the move is too vague and the smart cues won't work.

All I am saying is - simply - make dragging work the same as the select tool in scaling mode and in fact every other operation in VW I can think of. That is, make it work on the selected object.

[jan15]

... At the moment you can't click anywhere on an overlying solid and select it - you can only select it by clicking on an edge or vertex. ...

Is that something new in version 12? It's never been true in the past. A rectangle with no fill has to be grabbed at the edges; but if it has any kind of fill -- solid, pattern, hatch, gradient, or image -- you can grab the filled area and drag it away all in one click-drag.

[DDDesign]

No, I think you're mistaken, I've just checked v11, and it's the same.

[jan15]

It must be new with 11, then. Versions 8 and 10 work the way I described. I'm surprised I didn't read something about a change like that, affecting the filled surfaces that were always so fundamental to VW.

[Amy L]

I'm confused. I can easily select and drag a solid object from anywhere within the shape, as Jan states, as long as it has a fill (texture, color, hatch, etc.) Only when there is no fill do I have to grab an edge. Am I not comprehending something?

[DDDesign]

Are you really talking about a solid 3D object here?

[jeffroyer]

I find that 3d objects (say an extrude with solid fill) can only be picked by edge.

Oddly enough, floor objects behave like 2d rectangles which means they can be dragged from anywhere - a very annoying trait when you are zoomed in and don't realize you have in fact moved it without knowing it.