windowBoundingRect on multiple monitors? Is this a bug?

Paul Dupuis paul at researchware.com
Sat May 25 21:09:13 EDT 2019


Also, I just wanted to add that the windowsBoundingRect property - on 
the primary monitor - is helpful. We use it to limit maximize to a 
smaller area because we place a Toolbar palette under the menu and don't 
want maximized window to disappear behind the toolbar.


On 5/25/2019 9:04 PM, Paul Dupuis via use-livecode wrote:
> Mark,
>
> LiveCode, Ltd needs to put the contents of your brain in the LiveCode 
> documentation!
>
> Wow, thank you again for the ver helpful clarification. This will make 
> things much easier.
>
> Now, go back to bed and get some sleep!
>
>
> On 5/25/2019 8:21 PM, Mark Waddingham via use-livecode wrote:
>> 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 
>> not
>> 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 
>> will
>> 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 
>> missing
>> in the Mac port (although the code is somewhat murky so I could be 
>> wrong).
>>
>> Ultimately the WBR is an edge-case feature at most - mostly there for 
>> the
>> purposes of the IDE and similar tools and it is somewhat flawed for 
>> that.
>>
>> In its current incarnation it should both only apply to the primary 
>> screen,
>> and should be able to be set to empty so that the engine does not 
>> influence
>> what the OS tries to do with script supplied window rects at all.
>>
>> Warmest Regards,
>>
>> Mark.
>>
>> P.S. I think a work-around for now is to either set it to just the 
>> screenRect;
>> and if that does not work, set it to -8192,8192,8192,8192 and see if 
>> your
>> windows behave more appropriately.
>>
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode





More information about the use-livecode mailing list