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
____________________________________________________________________
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
