fullscreenmode and rect of a substack on mobile device ?

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

 > @ Richard I did not ask to a "simple" example.
 >
 > "Just yesterday I delivered a UI with several hundred controls on a
 > card, some quite deeply nested within groups.  But the layout did not
 > require writing anywhere close to one line per object.  Some was
 > handled in loops, others handled by simply grouping objects and
 > placing the group. Some don't need to be moved at all because their
 > natural placement relative to topleft need not change.  Others were
 > handled by combinations of the above in reusable behaviors."
 >
 > I want to see that e.g *as an actual stack*  - not a long explanation
 > of how it is possible, which you have to provide that on least 6
 > occasion that past two year. But but I want see code!

But but I want the time to do that!  :)

I would love to be able to deliver all sorts of example stacks, and I'd 
enjoy writing the tech notes to guide their dissection.  But the 
requirements of my work limit how much I can deliver here to an 
occasional description which may, admittedly, be unsatisfying.  If 
someone wants to send me a grant to spend a few weeks crafting 
instructional examples I'd prefer it over much of what I'm working on. 
But at the moment my obligations are where they are.

Besides, that particular layout was for an organization's internal 
needs, and even more relevant here than that it's proprietary to them is 
that their specific layout needs are unlikely to match the specific 
needs of your app.

So instead of throwing a pile of code over the wall as an irrelevant 
example of *what* to do for that one layout, it seemed more useful to go 
a level deeper and discuss *why* it's done which can help inform many 
layouts.

--

I used to hate writing object placement code.  In the olden days 
resizeStack handlers tended to be long monolithic blocks of code with 
cumbersomely long object references.  Mind numbing.

Then somewhere in the v5.x(?) cycle a small change was made to 
resizeControl that has big implications for layout management:

Previously, resizeControl was only sent to an object when it was resized 
interactively by the user with the pointer tool.

Today that message is also sent to a group when the group is resized by 
ANY means, including from another script.

That. Is. Big.

--

Most apps are comprised of regions, each of which contains controls or 
sometimes other sub-regions.  A navbar is a region comprised of a row of 
buttons, for example; a form is a region comprised of entry fields; etc.

Look at the apps you use, and think about them in terms of regions.

Regions of a screen are well expressed in LiveCode with groups.

With resizeControl triggered by scripts, instead of one long resizeStack 
handler in the card with tediously long object references, we can just 
set the rect of the few regions we have, and the mere act of adjusting 
our group rects will trigger the cascade of messages for each one.

Each group can then take care of itself.  And in doing so, the object 
references are much simpler. And the metrics are also simpler, able make 
use of the group itself as the bounds to work within.

Now you can modify the contents of a region, or even replace the group 
altogether, and all changes are localized in the group - nothing else is 
affected.

Add behaviors to the mix where useful, and things get ever simpler.

In broad terms:

- Consider UI patterns, look for sections that contain related
   functionality.

- Code the card for those regions. Its small resizeStack handler will
   trigger the cascade of resizeControl across the groups.

- Let the regions take care of their interior contents themselves.

- Nest groups wherever helpful, allowing each to enjoy
   the benefits of being self-contained.

- Use behaviors where practical.

Beyond that general gestalt of regions and localized code, another 
useful detail when placing things within groups under most circumstances 
is to set the lockLoc of the group and everything within it.  So much 
becomes so simple that way, and without it the automatic accommodate of 
interior objects within a group can sometimes be mystifying.  All that 
becomes confidently predictable with lockLoc.

--

None of this may matter much with regard to the app you're working on at 
the moment, since Jacque's description suggests it's a good fit for FSM, 
which you're already using.

So the description above may be more helpful for others, whose apps' 
layout needs follow more common patterns.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com