windowBoundingRect on multiple monitors? Is this a bug?

Mark Waddingham mark at
Sat May 25 20:21:33 EDT 2019

On 2019-05-25 23:19, Paul Dupuis via use-livecode wrote:
> If you have resizable windows, it is logical to set the
> windowBoundingRect to the working screenRect, so that windows that are
> zoomed (OSX) or maximized (Windows) are limited to the area of the
> primary monitor NOT being used for a menu bar or task bar.

Okay so you *shouldn't* have to do this - the windowBoundingRect does 
override the platform defaults... Which is to maximise the window within
the working area of the pertinent screen regardless.

Indeed, if you set the windowBoundingRect to the screenRect, a window 
still only maximise within the working area (i.e. the OS automatically
constrains things at least that much).

[ Note: You can still set windows to be where you want explicitly, this
   OS supplied effect only happens when you use the maximise button ]

> It seems to me that with the advent of multiple monitor support in
> 'the working screenRects' that there should either (1) be the
> windowBoundingRects (plural) with each one corresponding to each line
> of the screenRects OR (2) the windowBoundingRect be ignored on all
> monitors but the primary?

I think this might have been an oversight when we moved to Cocoa, there
is explicit code in the windows port at least to *only* apply the WBR
when the window's screen is the primary monitor. This appears to be 
in the Mac port (although the code is somewhat murky so I could be 

Ultimately the WBR is an edge-case feature at most - mostly there for 
purposes of the IDE and similar tools and it is somewhat flawed for 

In its current incarnation it should both only apply to the primary 
and should be able to be set to empty so that the engine does not 
what the OS tries to do with script supplied window rects at all.

Warmest Regards,


P.S. I think a work-around for now is to either set it to just the 
and if that does not work, set it to -8192,8192,8192,8192 and see if 
windows behave more appropriately.

Mark Waddingham ~ mark at ~
LiveCode: Everyone can create apps

More information about the use-livecode mailing list