loadStack message use cases

[Richard Gaskin]

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 
task done.

Currently we have:

preOpenStack       (card)
preOpenBackground  (each background group on the card)
preOpenCard        (card)
preOpenControl     (each group on the card)
openStack          (card)
openBackground     (each background group on the card)
openCard           (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* 
messages.

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.

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