ScreenRect bug or not

Richard Gaskin ambassador at fourthworld.com
Wed Jun 4 16:57:53 CEST 2014


Terence Heaford wrote:

 > This morning I have using LC 6.6.1 been through all my Geometry
 > settings to double check everything is working correctly. After a
 > few adjustments the Geometry settings are correct.
 >
 > Set LC 6.6.1 to liveResize = false and resizable	 = true.

Why set liveResizing to false?  Live resizing is very much the 
convention these days.  Even Apple's Garage Band, which has the slowest 
resizing behavior I've ever seen, does live resizing.

LiveResizing doesn't affect metrics; all it does it allow your stack to 
receive resizeStack events during the resize, rather than just getting 
one message when the resizing has completed.

 > Clicked on the green traffic light and the stack window zoomed to a
 > very odd size with the bottom right set to the bottom right of the
 > screen with a gap on the left similar to the width of the tools
 > palette(which is on screen)with a similar gap between the underside
 > of the menubar and the top of the stack window (icon palette not on
 > screen).

This is not a bug, but a design decision.  I don't agree with it myself, 
at least not as far as the left edge goes, but it's only this way in the 
IDE and is fully settable by the scripter.

The key here is the windowBoundingRect global property - worth a visit 
to the Dictionary.  By default it should be set to give you an 
appropriate full-screen zoom without modification, but you can modify it 
to accommodate things like toolbars if you like, which is what RunRev 
has done in the IDE.

Personally I think they should have left the left edge well enough alone 
(after all, the Tool palette is movable, and really only needed for a 
relatively short time during development, in the early stages when 
you're still laying out controls).  But the top modification is 
essential, for the reasons the windowBoundingRect was added, to allow us 
to support zoomable windows that don't submarine below the toolbar.


 > Gave up at that point and switched to LC 6.7 (dp 4)
 >
 > LC 6.7 still has liveResize = false and resizable = true.

Both of those properties are persistent so it's good to know they're 
being preserved as expected even in that deeply-modified test version.


 > Dragging by the bottom right of the stack window I noticed that
 > liveResize was active despite the setting being false? Is that
 > another bug?

If it's a newly created stack you'll find that liveResizing is now on by 
default for the last several versions.  It really is the norm, so this 
decision just makes it one step easier for us to make modern-looking 
apps, and as I noted doesn't affect metrics in any way, only the 
frequency of resizeStack messages.

If this is a stack which had its liveResizing off in earlier builds, and 
still shows liveResizing off even though it's exhibiting this behavior, 
this may be yet another case where Cocoa's assumption that the only 
thing you'll ever want to do is complete compliance with the OS X Human 
Interface Guidelines is making it hard to do anything else, and would 
warrant a bug report if one hasn't been filed for that test build already.

I should note that as valuable as it is for all of us to help with 
testing, v6.7 is a VERY exotic build, the first that uses Cocoa, meaning 
the first to attempt to merge LiveCode's object and messaging model with 
the limited and often strictly-enforced Cocoa way of doing things.

While you're still learning the nuances of all the flexibility LiveCode 
provides for window metrics, it may be best to stick with 6.6.2, which 
is also a test build but without the extreme changes Cocoa requires, and 
also very late-stage to it's quite stable and enjoyable to work with, in 
my experience.

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  Follow me on Twitter:  http://twitter.com/FourthWorldSys




More information about the use-livecode mailing list