stam wrote: ↑Thu Dec 14, 2023 2:54 am
This had been nagging at me but I only belatedly realised there was a whole page of 'interesting' debate I'd missed on this
I think the 'interesting' debate arose while you were at work
I now realise what the correct command to 'zoom' the stack should have been (i.e.
set the effective rect of this stack to the working screenRect), what using
the effective rect of the stack does to help this and what the
working screenRect (not the 'effective working screenRect') does
To be fair, whilst the 'effective' adjective when applied to objects is documented - its actual usefulness of when it is used on a stack is hidden in a 'note' in 'the rect of' property entry - the rect properties should probably have separate entries for being applied to stacks from regular objects because (as this discussions has shown) there are some important technical details here and really useful applications of it!
I also realized while responding to posts on this thread that the use of effective on the other rect-related properties (loc, width, height, left, top, right, bottom, topLeft, topRight, bottomLeft, bottomRight) are not documented either...
FWIW the reason is that originally effective *only* applied to `the rect` property and (internally) all those properties were implemented independently. At some point we unified the implementations of those properties (i.e. all now call a method which computes the rect and then the requested property is derived) - the goal there was cleaning up code, I don't think it ever occurred to anyone that we had (as a result) implemented effective variants of the entire set of those props!
[ As an aside, 'the effective rect of control' type syntax is actually redundant and has been for a long time - Ali and I have had discussions about repurposing it for more useful purposes as a read-only property in that case - i.e. one that actually does return the drawn pixel bounds of a control - although as with anything there's a fair bit of cruft to remove and figure out before we can do that. ]
On the point of the height of my apple menubar: aligning the top of a stack's titlebar to the menubar shows that it's 'top' is actually 66 - keeping in mind that the titlebar is 28 px, this means the Menubar on my system is 38 px high. but on the other hand, I now realise that knowing this doesn't change anything...
Hah - so its actually 'machine-type' specific - I'm sure Apple have some reason for that. I tried all the scaling settings on my iMac and the menubar was happily 25px in all of them.
I take it that `the working screenRect` does indeed return the *correct* item 2 for the menubar height regardless of the display scale you have on your laptop @stam?