loadStack message use cases
ambassador at fourthworld.com
Fri Aug 19 12:15:33 EDT 2016
Lagi Pittas wrote:
> I just did a test stack and it doesn't work the way I thought ---
> the event only goes to a group, it seems opencontrol and
> preopencontrol are not part of the methods of controls but groups.
> This means we have to do a repeat loop of each control in the group
> to set propertiesetc if you need to so maybe this should be extended
> to objects.?
The current design strikes what seems to be a good balance between too
few messages and too many.
On the one hand, messages are of course the life blood of event-driven
systems; without them data doesn't flow between the various things it
needs to, and the software organism suffers.
But on the other hand, messages take time and memory, so ideally we'd
have as few of them at any given time as we truly need to get a given
Currently we have:
preOpenBackground (each background group on the card)
preOpenControl (each group on the card)
openBackground (each background group on the card)
openControl (each group on the card)
Each needs to be packaged up and sent through the message path, and
collectively they offer tremendous flexibility with scoping.
The preOpenControl and openControl messages are sent only to groups
because they can be custom controls, which may in some cases require
special handling not normally easy to account for with the other *open*
The DataGrid is a good example here, because not only does it make good
use of those messages from a centralized behavior script the developer
using it needs to think about, but moreover it can contain hundreds or
potentially thousands of individual controls. If the preOpenControl
and openControl messages were sent to every control, the impact on card
opening could be staggering, limited in performance by the number of
controls on the card.
In those cases where we have a control or two that isn't a group and
needs initializing when opened, handling that in any of the existing
messages is a good option. And since most objects on a card won't
require initialization, this leaves the impact of card loading in the
hands of the developer, able to choose when and what gets handled when a
card is loaded.
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