Sannyasin Brahmanathaswami wrote:
> first: the resizeControl thing did not work out at all because it
> depends on the user resizing the stack.
The resizeStack message should be sent in response to anything that
causes the stack to resize.
This should not be limited to the user action of resizing a stack as we
often handle in desktop apps, but also whenever any script or the engine
causes the stack to resize.
On mobile OSes, a stack can only fill the device screen size, so a
resizeStack handler should be sent when a stack is first opened, and
when orientation changes, two events that cause the stack to be resized.
If the resizeStack message is used to adjust the rects of component
sections of the layout (groups), those groups should then be able to
adjust their interior contents in a resizeControl handler.
With such a setup the layout-specific code only adjusts the rects of a
relatively few groups, and from there the groups take care of
themselves. When any reusable groups are driven by behavior scripts,
code in one place allows reuse across nearly any UI.
FWIW I just added an answer dialog in my test stack's resizeStack
handler and indeed it triggers on both app open and device rotate as
described above. I'm using an engine for that testing built on v9.0dp4.
Since I'm testing on Android right now, if you're not seeing resizeStack
sent at app open and device rotate you may have found a bug specific to iOS.
It seems you've found a satisfying alternative here, so if it does what
you need use it:
> So it seems more "rock solid" and less "snakey" just to use the
> largest enclosing object at the bottom of the group as the reference
> coords. After that it's simple math and no caveats because you are
> establishing a "coordinate system" from the group with one object and
> reference everything from there, Suddenly it became very easy:
>
> on updateMyRect pRect
> lock screen
> put the long ID of img "info-bkgnd-img" into tFrame
> set the rect of img "info-bkgnd-img" to pRect
> set the width of grc "info-field-bkgnd" to (the width of tFrame) * .87
> set the height of grc "info-field-bkgnd" to (the height of tFrame)
* .87
> set the width of fld "info-text" to (the width of tFrame) * .80
> set the height of fld "info-text" to (the height of tFrame) * .80
> set the loc of grc "info-field-bkgnd" to the loc of tFrame
> set the loc of fld "info-text" to the loc of tFrame
> set the right of widget "close-info" to (the right of grc
"info-field-bkgnd" - 4)
> set the top of widget "close-info" to the top of grc
"info-field-bkgnd" + 10
> unlock screen
> end updateMyRect
>
>
> As for instantiation. We *do* use binary stacks as "views" so… just as
> we use a card to hold icons for buttons, that the user never sees.. so
> why not keep group controls in a stack and copy them… reserve the
> "dynamic creation from script" for a use case where this is your only
> option. or you *really* need to collaborate and want that all as text
> for GIT.
>
> so, then the last question is… where do you store the grouped
> controls… I guess you need a lib_template.livecode or something like
> that…. as long as it is in the stack files you will end up opening it
> as soon as you all it, the copy your assets out as needed ot the
> "current" GUI that needs them.
When I need one thing, I tend to store it where I use it. If it exists
once in a UI, I'll probably just build it there.
If I need multiple copies of things, scripts can copy faster than I can,
so I tend to put those (and behaviors, icon images, and other such
resources) in a substack or separate stack file named something like
"AppNameRSRC". The benefit of appending "RSRC" isn't just for ResEdit
nostalgia, but because the string both readily identifies the stack's
role as a resource container, and the all-caps abbreviation serves as a
clear reminder that it's not something we display to the user.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
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
