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
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
