Instantiaing Grouped Controls - Templates - Responsive

Richard Gaskin ambassador at fourthworld.com
Mon Jun 12 11:02:04 EDT 2017


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
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com




More information about the use-livecode mailing list