HELP!! - Geometry Gone Berserk, How to fix?
b.xavier at internet.lu
Sun Oct 9 08:30:50 CDT 2005
Hi David, dear list
as may know or not, Geometry is now one of my longuest lasting tortures in
rev... So here's hopefully some more information about what to do with the
revGM, what not to do, how to do it and more...
Also added are two scripts that can help David OR anyone with any GM issue -
it's the tip of the iceberg in GM management as I have developped it so far
for my needs in ever more intricate sub-gm-dependencies or atomical-modular
groups that just require one line handlers that don't interfere with
anything yet resize smoothly each time (and even permit themes and
It's not easy and nice as rev's GM but so far it has not broken ONCE! One
weird issue though - is that if you try to debug it, rev will crash! Funny
eh? So I wrote my own debugger for it too... All I mean to say is that there
is always a solution!
So here's the tip of the GM iceberg: save and restore a GM - no matter how
many controls. Note: the stack rect/size is not recorded - but easy to add.
But first a tip I remembered...
To prevent the rev GM from working while you resize a stack and it's
controls, it's imperative to put the following statement in you stack script
before resizing all your controls and saving the GM. This prevents
unfortunate resizes too.
-- comment out the resizestack handler if you have one already.
-- the revGM script blocker
When you have resized your controls correctly, comment the blocker handler
and uncomment the real resizestack.
The missing Pass resizestack statement in the blocker resizestack handler
will prevent the revGeometry manager from receiving events and rewrecking
the geometry - thank it's not a frontscript.
Avoid the the revpropertypalette and do it with your mouse! Some changes are
not detected by the GM and will penalize you again next resizestack happens!
BTW, most of this has been bugzillaed...
It's also possible that RevGM dependent controls might fail using other
align or property changing plugins - Test first...
Here's the first two GIM scripts that I wrote to save my GUIs from revGM...
It doesn't include the wipe-RevGM-props script which is quite longuer...
-- Save all positions in case of GM screws up
local clist, cid, crect
put the rect of this stack & CR into clist
repeat with x = 1 to the number of controls
put the short id of control x into cid
put the rect of control x into crect
put cid & tab & crect & cr after clist
delete last char of clist
set the OriginalGeometry of this stack to clist
local clist, cid, crect
put the OriginalGeometry of this stack into clist
set the rect of this stack to line 1 of clist
delete line 1 of clist
set the itemdelimiter to tab
repeat for each line L in clist
put item 1 of L into cid
put item 2 of L into crect
set the rect of control id CID to crect
if "grev" is in theglobals then
Now, in theory this should work BUT rev will screw your stuff again as soon
as you've not saved your stack! I've experienced this often with
excrutiating displeasure for 6 months before I abandoned RevGM ANYTHING. Man
was I going mad at the time!
In my professional opinion, the revGM is good for "simple stacks" given no
reverrors ever happen. Sometimes just resizing your stack after the error
will work or from a revupdategeometry called from the message box. If you
have controls that resize or move relative to other controls, avoid using
the rev GM, it will get lost sooner or later!
Maybe a rule of thumb in using the revGM is to implement it "strictly" just
before your release your stack or after all your controls are in their exact
I also wrote a GM missing-ID issue scanner stack which no one has mentioned
which identifies the problem GM entries which are not updated correctly by
the IDE engine - for example when a control with GM props changes IDs it can
cause lots of trouble to any related GM object!
(14 KBs zipped stack)
MonsieurX.com has another stack named GIM to replace the GM altogether with
one that will not fail! It also provides a many practical and scriptable GM
features like alignments, scaling, resizing, framing, zooming effects,
auto-menu placement and organization, etc...
There is no easy-palette to use with it yet... It's like any library, but
once you get used to it, it's quite fast and above all unbreakable...
The stack script is documented.
(285 KBs - rev stack)
This stack is part of a framework so the graphics may not show correctly.
hope that helps. Sorry for the length...
> -----Original Message-----
> From: use-revolution-bounces at lists.runrev.com
> [mailto:use-revolution-bounces at lists.runrev.com] On Behalf Of
> Jeanne A. E. DeVoto
> Sent: Friday, October 07, 2005 10:07 AM
> To: How to use Revolution
> Subject: Re: HELP!! - Geometry Gone Berserk, How to fix?
> At 12:11 PM +0100 10/6/2005, David Burgun wrote:
> >HELP! I have a Stack and the geometry has gone berserk. I have a
> >"breakpoint" inserted in a preOpenStack handler that allows
> me to quit
> >the startup path. If I let it continue the Stack displays and the
> >geometry has scaled/moved objects as if the Stack window were MUCH
> >bigger. If I Abort in the debugger, the stack displays ok.
> >However, if I type:
> >revUpdateGeometry (which would have been called on the preOpenStackk
> >path anyway)
> >The geometry goes beswick!
> >How it fix? Is there anyway of resetting the geometry of the Stack?
> With the stack in the correct state (e.g. if you abort), try typing
> in the message box. In theory this should rebuild the
> Geometry Manager settings, and base them off the current
> position and size.
> jeanne a. e. devoto ~ revolution at jaedworks.com
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage
> your subscription preferences:
More information about the use-livecode