VW2023 - always grabbing the object I don't want

[line-weight]

So ... I'm not 100% sure if this is new to VW2023, but I do feel it's worse, at least compared to 2021.

 

I am forever trying to get hold of some object, by one of its snap points, in order to move it. But what happens is that I end up grabbing something behind it, and moving it instead. Often, this is a floor or wall object and sometimes I don't even realise I've accidentally moved it until I find it in the wrong place at some later time.

 

The video below shows what happens. I want to select & move the front cube, not the back one. I make three attempts to select the front cube. The first and third attempts fail, the second one succeeds. Here is what I do to pick up the front cube:

 

- I hover the cursor near the corner of the front cube.

- The cursor changes to a cross icon (and the little red square appears on the snap point). To my mind, this confirms that VW understands this is the snap point I'm after.

- I know the red square is technically to let me then move the cursor to some perpendicular point or whatever. But once it appears, I don't then move the cursor to follow one of these snap lines. Again, the appearance of this plus the cursor changing, to me intuitively suggests that I've found the snap point.

- Then I press and hold the left mouse button

- What I want/expect to happen is that I will now have selected the front cube (the one the snap point belongs to) and will be able to drag it to some other location. When I release the mouse button, that's where the cube's snap point, the one I am holding onto, will be placed.

- That's not what always happens though: often instead the rear cube becomes selected, and of course moves if I then try and drag.

- I can see that the behaviour is determined by exactly where the cursor is, when I press the mouse button. If it's close to the corner but over the front cube, that's what gets selected. If it's close top the corner but over the rear cube, that gets selected.

- The problem is that even if you are very close to the snap point, or even, as far as can be discerned, exactly over it, you're liable to pick up the object you don't want.

 

Surely there should be some bias built in so that if the cursor is actually over the rear cube, but pretty close to the front cube snap point (and the cursor indicates that VW has found it), then the behaviour should be that the front cube is selected?

 

Feels like something has been tweaked because I don't remember having this frustration as much in previous versions.

 

 

 

 

[Tom W.]

I generally use the Move by Points Tool for most moving operations, probably I think as an (unconscious) reaction to this kind of thing happening too often.

 

 

[line-weight]

59 minutes ago, Tom W. said:

I generally use the Move by Points Tool for most moving operations, probably I think as an (unconscious) reaction to this kind of thing happening too often.

 

 

I've never actually used that tool.

 

I should probably try. But it seems to add a couple of extra clicks just to do some simple things.

[Tom W.]

For moving objects, perhaps, but at least you can be 100% confident your object is going to end up precisely where you want it.

 

But then there is duplicating/distributing objects (2nd + 3rd modes) + moving an object to a position a certain offset away from another object (4th mode), both of which are indispensable to me + are used constantly.

[zoomer]

I agree,

Select/Drag in VW works very well, for 80% of use cases

(Since the added the feature that it will care about selections and not switch to

the most top element when you click, in VW 2016 or so)

And with the CMD+D repeat feature it is pretty powerful

(but to abstract to use for me)

BTW I did not like/use the same tool in Microstation in the past

 

But for everything more complicated, I use Move/Copy by Points.

It is more familiar and like usual CAD Move/Copy Tools work.

And it got a bit better a few years ago but I still think it is totally

unnecessary tedious and inconsistent, but better than nothing.

 

When I first tested a VW trial I wasn't even able to reliably move/copy

anything in a controlled way with either of both Tools.

[Christiaan]

11 hours ago, line-weight said:

I am forever trying to get hold of some object, by one of its snap points, in order to move it. But what happens is that I end up grabbing something behind it, and moving it instead. Often, this is a floor or wall object and sometimes I don't even realise I've accidentally moved it until I find it in the wrong place at some later time.

Screen Recording 2023-02-23 at 17.21.24.mov 2.24 MB · 0 downloads

 

This is something wrong with the algorithm VW uses to decide what you're trying to pick up, right? Seems to me it needs to give more weight to foreground objects and actual snap points. I experience this in complex models all the time but your screen recording is a really great example of how bad it actually is because it's such a simple model.

[line-weight]

1 hour ago, Christiaan said:

 

This is something wrong with the algorithm VW uses to decide what you're trying to pick up, right? Seems to me it needs to give more weight to foreground objects and actual snap points.

Yes exactly.

 

But I think that as soon as the cursor is telling you it's found a snap point, then it should always be that snap point that you pick up if you press the mouse button. Otherwise what's the purpose of the cursor hint?

 

And the video below shows how it makes it so easy to move other objects unintentionally, if their bounding box is not visible when you're doing the move operation.

 

 

Edited February 24, 2023 by line-weight

[Tom W.]

This is same operation with Move by Points:

 

 

 

But I agree, I would do it by clicking + dragging if it wasn't for the behaviour you're talking about.

[Tobias Kern]

Hi

 

for me grabbing feels also worse compared with older versions.

I think also auto-pane is affected.

Hope we see improvements in this behavior!

 

I also would like to see improvements in Push/Pull-surface-selecting.

I wrote a wish, that the current active object, will be more in focus for

Push/Pull than the non-active objects.

 

I always group my object + do my push/pulls inside the group and

ungroup it afterwards.

 

If you want to vote/support/push my ticket, it is VE-104051.

 

Greetings and have a nice weekend.

Tobi

[line-weight]

30 minutes ago, Tobias Kern said:

 

I also would like to see improvements in Push/Pull-surface-selecting.

I wrote a wish, that the current active object, will be more in focus for

Push/Pull than the non-active objects.

 

 

There is a long running thread on push pull problems

 

https://forum.vectorworks.net/index.php?/topic/51856-vw-2018-and-vw2021-and-vw2022-push-pull-tool-problems-continue/page/5/#comment-423987

 

It seemed that some significant improvements were made in VW2022

 

But I do feel that I too am finding some problematic push-pull tool behaviour in the current version of 2023. Faces sometimes refusing to select. Not as bad as it has been, but it's still there.

 

 

[Christiaan]

Another way this manifests is when re-associating Data Tags to windows on a (SLVP) elevation view of a model. If there's a window behind on the other side of the building it will try to associate with that instead. Bonkers.

[AlanW]

Hi I often hold the B key to select item and you can get a better selection option and then there is the hold J key and you get options of objects to select if you are over multiple objects. HTH

[Tom W.]

14 minutes ago, AlanW said:

then there is the hold J key and you get options of objects to select if you are over multiple objects

 

I would be very happy if 'Select Coincident Objects...' worked with Data Tags...

 

[Christiaan]

On 2/27/2023 at 8:49 PM, Tom W. said:

 

I would be very happy if 'Select Coincident Objects...' worked with Data Tags...

 

Usually if I spend enough time trying I can re-associate a Data Tag to a problematic window on an elevation but I found a very good example yesterday where it's impossible, so submitted a bug. The only solution was to apply a new Data Tag.

[Tom W.]

1 minute ago, Christiaan said:

Usually if I spend enough time trying I can associate a Data Tag to a problematic window on an elevation but I found a very good example yesterday where I just can't re-associate it, so submitted a bug.

 

Yes I have had instances where it has proved simply impossible to tag an object because another object gets in the way + refuses to budge (even though in the model that object is behind the object I'm seeking to tag). I have ended up having to use a user-entered-data version of the tag + type in the text manually...

 

I have also found that symbols inserted in Slabs are completely invisible to Data Tags meaning a manually-entered tag is required there too... This is surprising as to a lay-person, a symbol inserted in a Slab is no different to a symbol inserted in a Wall (door, window, etc) + yet as far as VW is concerned it is different because Data Tags can't 'see' them. Perhaps the reengineering of Slabs that @Matt Panzer mentioned elsewhere will address this... I don't think I've tried tagging a symbol inserted in a Roof so can't say whether it's the same phenomenon there or not.

 

Despite all this I still flipping love Data Tags

[Christiaan]

Indeed, in fact I just found a window in that same elevation that I cannot tag with the right number. 

[Tom W.]

And B key no use?

[Christiaan]

B key no use.

[Tom W.]

25 minutes ago, Christiaan said:

B key no use.

 

Thanks for confirming. Same as me then.

[Matt Panzer]

On 3/4/2023 at 5:14 AM, Tom W. said:

 

Yes I have had instances where it has proved simply impossible to tag an object because another object gets in the way + refuses to budge (even though in the model that object is behind the object I'm seeking to tag). I have ended up having to use a user-entered-data version of the tag + type in the text manually...

 

I have also found that symbols inserted in Slabs are completely invisible to Data Tags meaning a manually-entered tag is required there too... This is surprising as to a lay-person, a symbol inserted in a Slab is no different to a symbol inserted in a Wall (door, window, etc) + yet as far as VW is concerned it is different because Data Tags can't 'see' them. Perhaps the reengineering of Slabs that @Matt Panzer mentioned elsewhere will address this... I don't think I've tried tagging a symbol inserted in a Roof so can't say whether it's the same phenomenon there or not.

 

One of the things we want slabs and roofs to be on par with walls is how they take inserts.  If they were implemented in a similar way, I would think Data Tags would just work with their inserts.  In any case, we need to make sure they do work with them. 🙂 

[Tom W.]

2 minutes ago, Matt Panzer said:

 

One of the things we want slabs and roofs to be on par with walls is how they take inserts.  If they were implemented in a similar way, I would think Data Tags would just work with their inserts.  In any case, we need to make sure they do work with them. 🙂 

 

Matt next you're going to be telling us we'll be able to use texture mapping on Slab components as well 🙂 

 

Good luck with all the reengineering + look forward to seeing the results. Thanks for filling us in

[Matt Panzer]

Just now, Tom W. said:

Matt next you're going to be telling us we'll be able to use texture mapping on Slab components as well 🙂 

 

Well... let's not get ahead of ourselves. 😉 

That's certainly up on our list.

 

Just now, Tom W. said:

Good luck with all the reengineering + look forward to seeing the results. Thanks for filling us in

 

Thanks Tom and you're very welcome!

[Tom W.]

20 minutes ago, Matt Panzer said:

Well... let's not get ahead of ourselves. 😉 

That's certainly up on our list.

 

Ha ha good!