Screen.AvailableTop not ScaleFactor savvy? aka inconsistencies in screen properties

By the docs, Screen.AvailableTop will deliver the first “usable” y-coordinate (top to bottom) of a screen in pixels. Ok, so you have to multiply this value by Screen.ScaleFactor to get the real value.

BUT: By the docs, Screen.AvailableHeight will also return the usable screen dimension in pixels. It does not; this value is returned in points, you do not have to multiply it with ScaleFactor to get the real value. Like you don’t have to for every window dimension property.

Do we have another Xojo design flaw here or am I wrong in meaning AvailableTop should also return point values like everything connected to window/screen on macOS?

Addition: AvailableTop on macOS Big Sur returns 25. Retina makes it 50. If I place the window at this point, its upper frame will be cut by the menu bar. Manually dragging it and pushing it as high as possible tells me the real value should be 53.
Therefore: Is AvailableTop reliable at all?

AvailableTop returns points.

I think your problem may be in that window.top is the top of the contentView of the Window, this does not include the “Chrome”.

Either use window.bounds to set the frame of the window (including the Chrome) or use ( window.top - window.bounds.top ) to figure out the height of the “Chrome”.

Oh gee. Thanks, Sam. I am so used to think in native frames that it did not occur to me in Xojo I have to use bounds instead …

1 Like