Thanks Robert. It does sound like I will need to do the resizing by
script as you say. But I'm confused about the geometry manager. It
doesn't appear to do anything right now even though all the objects
I've looked at are set to scale when the window resizes (the
default). If I write my own geomanager, do I have to do something to
stop the LC geomanager doing things in addition to what I do in my own
geomanager (even though it appears to do nothing right now)?
The reason the geo management issue came up is to deal with different
screen resolutions. What I need to do is figure out the screen
resolution at startup and if it has changed since the last time the
app was run, call my resizing handler to deal with the new screen
resolution. If I do allow the user to change window sizes, I could of
course use the same resizing handler but the main use right now is to
deal with screen resolutions.
There are other issues I'm sure, for example if I resize a field
control, do I need to reset the font size? I guess it's the fear of
the unknown that is making me consider just grouping all the objects
on the card together and adding scroll bars to the group so the user
can scroll around the window when necessary. It seems like that's
pretty easy to implement but I would need to see it in action to know
whether it would be acceptable to the user.
Pete Haworth
On Dec 21, 2010, at 10:36 AM, Robert Brenstein wrote:
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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
