Send the Stack to the Center of the screen.

[richmond62]

Yes - but that's what you have asked for!

NO: I most definitely did not ask for that.

I asked for the grab bar of the stack being scaled to be directly beneath the MacOS Menu bar, and, as you can see in that screenshot it is 74 points below the top of the screen when it should be about 53.

[LCMark]

NO: I most definitely did not ask for that.

Heh - when I said 'what you asked for' I meant in terms of 'what you are asking the engine for' - i.e. in terms of the code you tried.

In case my previous post was not entirely clear - if you remove the second line which resets the loc of the stack to something else - then you should find you get what you actually wanted... All in a single line.

i.e.

Code: Select all

on mouseUp
    set the effective rect of stack "screen Stretch" to the working screenRect
end mouseUp

[richmond62]

Heh - when I said 'what you asked for' I meant in terms of 'what you are asking the engine for' - i.e. in terms of the code you tried.

Should I laugh or cry?

So:

Code: Select all

on mouseUp
    set the effective rect of stack "screen Stretch" to the working screenRect
end mouseUp

DOES set the grab bar of the stack to directly under the MacOS Menu bar.

It is still NOT doing quite what it should with the MacOS Dock:
-

-
I am now going to shrink my Dock and see if things are 'improved'.

Hmm . . . that DOES work 'perfectly':
-

-
And, Oddly and Oddlier, on magnifying the Dock to my 'habitual size' it is 'perfect' again:
-

-
HOWEVER, as, on my initial attempt things were not 'perfect' I would argue there is something going on which is not quite right: after all one cannot expect an end-user to have a "yogic stretch" with their MacOS Dock to ensure that any scaling will avoid the Dock.

[LCMark]

DOES set the grab bar of the stack to directly underr the MacOS Menu bar.

It is still NOT doing quite what it should with the MacOS Dock:

Hmmm - I don't see that here - so there is something amiss somewhere.

I tested the provided line on my desktop mac (macOS Sonoma / Intel) for a variety of dock sizes (before I posted it) and in all cases it did precisely what it should - the edges of the window frame are immediately below the menubar and immediately above the dock. [ I also tested on Ubuntu 22.04 as I happened to have that VM opened, and it worked correctly there as well ].

Do you see the same problem if you create a brand new stack, and then in the message box do:

Code: Select all

set the effective rect of this stack to the working screenRect

If so, then that rules out it being something to do with that specific stack.

Failing that, what mac are you trying on? (Processor / OS version etc.) and, perhaps more importantly, what version of LiveCode?

[richmond62]

I have just tested a NEW stack on MacOS 12 Monterey with LC 10 dp 7 and that works perfectly.

AND I have just tested the same stack on MacOS 12 Monterey with LC 9.6.3 Community (my normal weapon of choice) and that works perfectly.

I also tested the same stack on MacOS 12 Monterey with "something I am not meant to mention hereabouts" (my secondary weapon of choice) and that works perfectly.

So, probably, my "screen Stretch" stack had, somehow, been 'poisoned' by my earlier experiments.

Thank you for all your help.

[LCMark]

The one limitation is the hardcoding of the Apple menubar height - we would ideally have a handler to provide the current menubar's height, but as far as I can see online this would need a Swift or Ojb-C call (i.e. an external).

Or even better, LC would fix the effective working screenRect so it does this automatically - and would probably fix the slight slippage I'm seeing on revMenuBar on MacOS, which is hanging about 3-4 px below the apple MenuBar...

@stam:

So `item 2 of the working screenRect` should give you the height of the menubar - which appears to be 25px on Sonoma (here, at least)*. The height of a window's title bar is 28px though - so I think that's why you need that adjustment in your provided code to make it work (and might be avoidable by appropriate use of 'effective' on the stack rect etc. - or indeed you can calculate it by taking the difference between item 2 of the effective rect and the rect of a stack).

I'm a little puzzled by the slippage of your revMenuBar though - on my mac (Intel Sonoma) it happily sits right below the menubar with no space. Has it always been like that? Only like that on that machine? If you get a chance can you see if resetting your preferences puts it back where it should be?

* I've now read the rest of what @stam said and he said it can vary by resolution chosen and perhaps even architecture so that needs further investigation (FWIW, the engine fetches the working screenRect info from the OS, there aren't any constants floating around!)

[richmond62]

The height of the MacOS Menu bar on MacOS 12 Monterey is 25 so this statement:

The MenuBar on MacOS has got bigger with Sonoma

looks a bit odd.

My MacOS Sonoma machine is at work (Wednesday is a non-working day for me), so cannot test the Menu bar height myself until tomorrow.

[bn]

I'm a little puzzled by the slippage of your revMenuBar though - on my mac (Intel Sonoma) it happily sits right below the menubar with no space. Has it always been like that? Only like that on that machine? If you get a chance can you see if resetting your preferences puts it back where it should be?

My revMenubar also slipped a couple of pixel down since yesterday. I have no idea why.

I cured from the message box

1:

Code: Select all

dispatch "revIDEPositionPaletteDefault" to stack "revIDElibrary" with "revMenubar"

and revMenubar moved up to where it should be.

If that is ok then

Code: Select all

dispatch "revIDESetPaletteRectPreference" to stack "revIDElibrary" with "revMenubar"

I restarted LC and revMenubar was at its expected location.

KInd regards
Bernd

[stam]

So `item 2 of the working screenRect` should give you the height of the menubar - which appears to be 25px on Sonoma (here, at least)*. The height of a window's title bar is 28px though - so I think that's why you need that adjustment in your provided code to make it work (and might be avoidable by appropriate use of 'effective' on the stack rect etc. - or indeed you can calculate it by taking the difference between item 2 of the effective rect and the rect of a stack).
<snip>
* I've now read the rest of what @stam said and he said it can vary by resolution chosen and perhaps even architecture so that needs further investigation (FWIW, the engine fetches the working screenRect info from the OS, there aren't any constants floating around!)

I googled the menubar height and found a number of posts like this one: https://bjango.com/articles/designingme ... a%20pixels.

On a 14-inch MacBook Pro the menu bar can be 27pt, 29pt, 34pt, 37pt, or 43pt tall, depending on the display scaling setting. On a 16-inch MacBook Pro, it's almost the same, but the middle display scaling menu bar height is 33pt, rather than 34pt

EDIT: I only belatedly noticed the many, many posts above and deleted the remainder of this post as it was superfluous and already answered...

[stam]

Code: Select all

dispatch "revIDEPositionPaletteDefault" to stack "revIDElibrary" with "revMenubar"

and revMenubar moved up to where it should be.

If that is ok then

Code: Select all

dispatch "revIDESetPaletteRectPreference" to stack "revIDElibrary" with "revMenubar"

As always you're spot on the money Bernd!
This was my revMenuBar previously:

I followed your recipe and it's now fixed! Thank you!!

[stam]

So `item 2 of the working screenRect` should give you the height of the menubar - which appears to be 25px on Sonoma (here, at least)*. The height of a window's title bar is 28px though - so I think that's why you need that adjustment in your provided code to make it work (and might be avoidable by appropriate use of 'effective' on the stack rect etc. - or indeed you can calculate it by taking the difference between item 2 of the effective rect and the rect of a stack).

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

On a sidenote, these issues are identical on Windows so Paul's code would have had the issue of the missing titlebar no matter the platform, and clearly it was never the apple menubar at fault, but as usual my code - iv'e adjusted my handler I posted previously to reflect this.

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

Well at least I learned a few things from this
And special thanks to @LCMark for his patience and @bn for finally providing a fix for the drooping revMenuBar!

Stam

[LCMark]

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?

[richmond62]

As far as the 'interesting' bits of this debate extended they was only 1:

1. The under-documented nature of what was discussed.

To be honest I think that this:
-

-
does NOT make it clear that effective does not have to be present.

Had that been made explicit I might not have made such a fool of myself getting my stack 'stuck' behind my MacOS Dock.

[stam]

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?

Hi Mark - yes.
Setting the rect of the stack to the working screenRect puts the top of the content of the stack below the menubar, hiding the titlebar.
Setting the effective rect of the stack to the working screenRect shows the full window, with the titlebar aligned at the menubar.

I'm not sure I understand how the effective screenRect is different from the screenRect though...

Would it be appropriate to include this tidbit in the screenRect's dictionary entry?
The actual text in Description of this entry is a bit laconic and perhaps impenetrable to new users...
As with many dictionary entries, multiple examples would be invaluable to both new and experienced users...

Many thanks!
Stam

[bn]

I'm not sure I understand how the effective screenRect is different from the screenRect though...

Would it be appropriate to include this tidbit in the screenRect's dictionary entry?
The actual text in Description of this entry is a bit laconic and perhaps impenetrable to new users...
As with many dictionary entries, multiple examples would be invaluable to both new and experienced users...

From the current dictionary entry for screenrect

Adding the effective adjective to either form returns the area of the
screen the application has to itself. In particular, if the keyboard is
activated, it take into account if the keyboard is taking up space on
the screen. (Android and iOS only)

Kind regards
Bernd