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

Reply via email to