LiveCode Forums.

I made a simple test stack to show how one can snap a particular point of one control, like its corner, to another "point" of interest, like a corner or the midpoint of a side, on another control. Works fine, though I do not expect to be able to create another SolidWorks out of LC.

But there is something amiss, and it has to do with my LC understanding of the bounds of a control. In the stack, with the optionKey down, one may drag the small field around the card, and if its botLeft gets near the topRight of the larger field, it will snap to that point.

But release the optionKey to leave the small field in place, and there is a gap visible between the two controls at what should be their shared point. The topRight of the larger field is the same as the botLeft of the smaller, but they do not visually coincide.

What is the point?

There is a similar handler in the small field script that allows one to set the botLeft of the small field to the midpoint of the right side of the larger. Same issue there.

Craig

I didn't look at your stack, but made my own.
- -
The Bottom Right of the field is 150, 90

The Top Left of the button is 150, 90

And, Yes: there is an extremely visible gap between them.

LC Community 9.6.3

Richmond.

I am wondering if this is some sort of optical illusion, based on the fact that a screen can only do so much to render and locate objects on itself accurately.

With a loupe on my monitor I see many more pixels, about twice the pixel density, than what typically is the resolution of "one pixel" that we are used to when manipulating objects with the several programs we all use every day. Maybe this is all a rounding error?

Craig

Here's another silly picture:
- -
What I notice is that the selection handles are "fatter' on the outside of an object than inside.

So this tells me that those points are "off".

Richmond.

The selection handles are not considered any part of the geometry of the objects, rather only temporary aids. Only the rect of an object matters.

Craig

Only the rect of an object matters.

You'd have thought so, wouldn't you.

But there is something a bit odd when the same set of points result in 2 things being separated by an empty patch.
- -
There's no gap between his 2 front teeth: honest!

Richmond.

A "point" is not a mathematical point, but rather a blotch. It has a length and width, based on the measurable pixels that form the display. So where do we "locate" the, er, loc of such a smear?

At the center? Likely it is instead at the "outer" extreme. In CAD programs that have adjustable line widths, the outermost portion of a line sets the value of its thickness. I am sure LC does the same.

So again, Is there really a gap, or is it an illusion caused by the screen doing its best with not-infinitely-small pixels?

Craig

Richmond.

Terry-Thomas looks SO British; the gap only helps. Even the dash in his name screams that out.

Craig

Maybe it's just an optical effect. Because if you change the background color of the fields and set the showBorder property to false. It is seen that they are indeed where they should be.

Andresdt.

AHA.

So it is just screen rendering doing its best in a clunky world.

Craig

a clunky world

Indeed: ROFL.

Just upgraded my 2018 Mac Mini to MacOS 15 Sequoia . . .

I suspect it’s because borderwith of either object has not been taken into account…

Stam.

If I read your post correctly, that would cause the two objects to appear to overlap, not (appear to) fail to meet, no?

Craig

Yeah that's right. I mean, they either overlap on 1 dot, or there is a gap, which if I understood correctly, is what you were trying to solve.

this modification to your code seems to make it work well, but is not generalisable (ie assumes we're only talking about the bottomLeft->topRight and that the borderWidth of both objects is 1)
This makes it look like this:

I think this has somehow to do with the cartesian coordinates that start at 0,0. TopLeft is within the rect, botRight is outside.
Kind regards
Bernd