Inconsistent Dock Behaviour apparently caused by "Move to Upper Right of Page"

Hi All,
It’s taken me months to finally capture a repeatable set of steps that demonstrate an issue with the Dock Arrange Tool. In this particular use case an object is duplicated. the original object is moved to the top right hand corner of the page using the “Move to Upper Right of Page” command. The duplicate object is moved to the bottom left corner using the “Move to Lower Right of Page”. This object is selected and the “Dock objects upwards” is clicked (padding set to 0mm). Instead of aligning to the bottom of the top object, the docked object completely overlays the top object.

What I have found is that if an object is moved from a +ve X coordinate using “Move to Upper Right of Page” the resulting Y coordinate is set to -0.00 which seems to make the Dock tool think the object is not entirely with the page boundary. If however the object is dragged to a -ve X position, then the “Move to Upper Right of Page” sets the Y value to 0.00 and the dock works correctly.

I also cannot see a good reason for the Dock tool to ignore objects not completely within the page especially if you’re into cutting things bigger than your machine’s X dimension using Print & Cut?

I’m using LB 1.7.08 on MAC and 1.7.02 on Win which both exhibit the behaviour. As I have had some issues with docking for some time (not sure if started at 1.5.x or 1.6.x) I downgraded temporarily to v1.4.05 which does not have this issue.

If you wish to attempt recreating the issue please used the attached file and follow the above steps Exactly dock strangeness.lbrn2 (10.8 KB)

There is also a youtube video I’ve posted at https://youtu.be/2QoGpVZwkEs that demonstrates the issue. video should be public at 16:00 UK time

Cheers,
Dave

That’s a known bug we discussed some months ago, I have to search for the post. At the time, it was on the to do list, but it might not have been tackled yet.

Ah, no. There was no interaction with the team, so that bug might not be on the list. So it was good to rise it again. :grinning_face:

1 Like

@misken, Is there a Known Problem File/List that we can look at before posting, that would also show the status regarding the Dev team’s involvement? Visibility would improve efficiency.

I don’t think there is a public list. I don’t know if it’s possible to share one, the team would have to check this :grinning_face: @gilaraujo

1 Like

I said originally that I wasn’t sure if this behaviour started in 1.5.x or 1.6.x, but I’ve now tested against more old releases and found that the “bug” was introduced in 1.6.00. I had a look at the New Features list in the dev blog for 1.6.00 and it made me wonder if it might have something to do with code changes to support negative workspaces for Galvo’s despite the fact I’m on Ruida?..pure conjecture of course :wink:

1 Like

…and the problem is also in 2.0.2

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.