What is the point???

[dunbarx]

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

Poor man's snap.livecode.zip

(1.16 KiB) Downloaded 94 times

[richmond62]

I didn't look at your stack, but made my own.
-

SShot 2024-06-12 at 17.09.47.png (4.33 KiB) Viewed 3687 times

-
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

[dunbarx]

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

[richmond62]

Here's another silly picture:
-

SShot 2024-06-12 at 17.31.26.png (4.96 KiB) Viewed 3677 times

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

[dunbarx]

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

[richmond62]

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

terry-thomas.jpg (22.73 KiB) Viewed 3662 times

-
There's no gap between his 2 front teeth: honest!

[dunbarx]

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

[dunbarx]

Richmond.

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

Craig

[andresdt]

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.

[dunbarx]

Andresdt.

AHA.

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

Craig

[richmond62]

a clunky world

Indeed: ROFL.

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

[stam]

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

[dunbarx]

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

[stam]

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)

Code: Select all

on mousemove --to the corner
   if the optionKey is down then set the loc of me to the mouseLoc
   
   if abs(item 1 of the botLeft of fld "F1" - item 1 of the topRight of fld "F2") < 8 and \
         abs(item 2 of the botLeft of fld "F1" - item 2 of the topRight of fld "F2") < 8 then \
            set the botleft of fld 1 to right of fld "f2" - 1, the top of fld "f2" + 1
end mousemove

This makes it look like this:

Screenshot 2024-06-13 at 13.02.44.png (9.98 KiB) Viewed 3546 times

[bn]

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

Code: Select all

on mouseUp
   put the rect of field 1 into tRect
   put item 1 of tRect, item 2 of tRect into tTopLeft
   put item 3 of tRect, item 4 of tRect into tBotRight
   put "topLeft is within: " & (tTopLeft is within tRect) & cr & "botRight is within: " & (tBotRight is within tRect)
end mouseUp

Kind regards
Bernd