Geometry Manager Re: Stack window/screen sizes

Peter Haworth pete at mollysrevenge.com
Tue Dec 21 18:34:47 EST 2010


Thank you!  I just looked at the lesson and it odes indeed clarify  
things.  I think I have a huge amount of work ahead of me though since  
I have many screens and some of them have a large number of objects  
that will need to be resized.

I do use a lot of my own cprops so unfortunately won;t be able to use  
the code snippet you gave for getting rid of the Geometry manager  
properties.  But if I am understanding the user guide correctly, if I  
don't pass the resizeStack message, the geometry manager will never  
see it and so won;t do anything.

I am now thinking that I may be able to make use of my own custom  
properties along with some common code to implement all this.  Without  
that, it sounds like thousands of lines of code.  Alternatively, I'm  
naively hoping that I might be able to write some code that will  
simply adjust the size of controls and the distance between them based  
on the ratio between the old and new screen sizes.  For example, if  
the user reduces the screen size by 10% horizontally, it seems like I  
should be able to reduce the width of all the controls and the  
horizontal distance between them by 10% and everything should fit.   
I'm sure I;d need a way to deal with exceptions (cprops?).  Is that  
too simplistic?

Pete Haworth

On Dec 21, 2010, at 2:36 PM, Björnke von Gierke wrote:

> Hi Peter
>
> I made a lesson because of your confusion, maybe it helps? It's  
> called "How to manage and position objects when a stack is resized".  
> If you create the code by yourself, then you at least know who  
> messed up your stack ;)
>
> http://tinyurl.com/2adxkwq (leads to runrev.com lesson site)
>
> As for the Geometry manager, it works by adding hidden  
> customproperties to every object. A front- or backscript that is  
> part of revGeneral will check for these properties, and adjusts the  
> objects rectangle. revGeneral is a button that is part of the IDE,  
> and also added by the application builder, whenever you build a  
> standalone. The properties are hidden by the IDE, and they are also  
> called revGeneral (note that there's other, non-geometry stuff  
> stored there too, like standalone builder settings). As you found  
> out, the geometry manager is not only highly unreliable, but also  
> confusing and moving objects every which way almost instantly.
>
> I am sure this explanation doesn't help you tho. So rest assured  
> that coding your own is not only less confusing, but also easier to  
> maintain. So, to get rid of the geometry manager stuff, you just  
> need to delete all of the cpropsets. For example, from the multiline  
> message box, or some other script you can do the following (Warning:  
> only do it this way if you do _not_ use custom properties yourself,  
> and don't mind to set up the application builders settings from  
> scratch):
>
> repeat for the number of cards
>  add one to y
>  repeat for the number of controls
>    add one to x
>    set the custompropertysets of control x of card y to ""
>  end repeat
>  set the custompropertysets of card y to ""
> end repeat
> set the custompropertysets of this stack to ""
>
> On 21 Dec 2010, at 20:29, Peter Haworth wrote:
>
>> Thanks Damien.  I've downloaded it and will give it a try.
>>
>> Pete Haworth
>>
>> On Dec 21, 2010, at 10:47 AM, Damien Girard wrote:
>>
>>>
>>> You can also take a look at NativeGeometry that will handle for  
>>> you all the
>>> geometry management ;)
>>>
>>> http://www.nativesoft.fr/nativegeometry
>>>
>>> Kind Regards,
>>>
>>> Damien Girard
>>> NativeSoft, France.
>>>
>>> -----Message d'origine-----
>>> De : use-livecode-bounces at lists.runrev.com
>>> [mailto:use-livecode-bounces at lists.runrev.com] De la part de Robert
>>> Brenstein
>>> Envoyé : mardi 21 décembre 2010 19:36
>>> À : How to use LiveCode
>>> Objet : Re: Geometry Manager
>>>
>>>
>>> On 21.12.2010 at 10:13 Uhr -0800 Peter Haworth apparently wrote:
>>>> Just started trying to figure out the geometry manager.  It appears
>>>> there is already a default for every control to scale it when the
>>>> user resizes the window.  Problem is, it doesn't happen.  If I
>>>> resize my window, all the controls on it that fall completely
>>>> outside the boundary of the window disappear and any that are
>>>> partially outside the window are cut off.
>>>>
>>>> I'd also add that I tried looking in the LC preferences to see if
>>>> there was a setting to enable/disable the geometry manager and,  
>>>> with
>>>> glx2 installed, the only preferences that I could get to were the
>>>> glx2 ones, not the LC ones.
>>>>
>>>> Pete Haworth
>>>>
>>>
>>> As others suggested, rolling your own geometry management is
>>> recommended for more complex situations. The built-in geometry
>>> manager works but to a certain complexity only, and when it breaks,
>>> the time and effort invested in setting it up will got to waste. You
>>> have indicated that your stack is not simple, so going with the
>>> built-in manager is not recommended. Others have already hinted that
>>> geometry management is not that difficult to program. Typically, you
>>> will have
>>>
>>> on preOpenCard
>>> -- accommodate user-inflicted resizing which occured on another card
>>> myGeomMgr (the width of this cd),(the height of this cd)
>>> end preOpenCard
>>>
>>> on resizeStack pNewWidth,pNewHeight
>>> -- accommodate user-inflicted resizing on this card
>>> myGeomMgr pNewWidth,pNewHeight
>>> end resizeStack
>>>
>>> on myGeomMgr pNewWidth,pNewHeight
>>> -- card level geometry manager
>>> constant cMargin = 25
>>> # do the magic with bg objects
>>> myBgGeomMgr pNewWidth,pNewHeight -- optional
>>> # do the magic with card groups
>>> myGrpGeomMgr pNewWidth,pNewHeight -- optional
>>> # do the magic with cd objects
>>> ...
>>> -- an example resizing a field
>>> set the width of fld kListFld to pNewWidth-2*cMargin
>>> set the left of fld kListFld to cMargin
>>> ...
>>> end myGeomMgr
>>>
>>> Such a setup allows you to call your geometry management also from
>>> scripts, and allows you to pass parameters between scripts, if
>>> needed. Normally, one positions/resizes objects relative to card
>>> edges and other objects, dealing with width and height of each
>>> object. The order of positioning/resizing is often critical.
>>>
>>> Robert
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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