Fwd: Quantum tunneling in LiveCode

[Michael Doub]

Richard,  Very nice explanation of this.   I always wondered about the 
relationship between this properties.

Thanks,
    Mike

On 3/3/15 10:13 AM, Richard Gaskin wrote:
> Stephen Goldberg wrote:
>
> > I think the bottom line is to be cautious about putting mouseUp
> > scripts in background groups, or to put a disclaimer in the group
> > at the beginning of the group handler the line (as mentioned in
> > the User Manual (pg 131, 5.3.9):
> >
> > if the owner of the target is not me then pass mouseUp
>
> The backgroundBehavior property is a tricky thing, implemented for 
> compatibility with imported HyperCard stacks but given the differences 
> between the HC and LC object models it's always going to be at least a 
> little mind-bending.
>
> In HC, there was always and only one background, which was placed 
> below the card.
>
> In LC, there is no "background" object pe se, but instead employs 
> groups which can be shared across cards.  In LC we can have any number 
> of groups, and they may even be nested.
>
> In LC, in the absence of an always-present background object, all 
> objects always reside on the card.
>
> To maintain compatibility with HC, the backgroundBehavior was 
> introduced in an attempt to account for those cases where the message 
> handling order needed the background after the card, as it was in HC, 
> rather than before the card as is natural in LC.
>
> In older versions of LC setting the backgroundBehavior was the only 
> way to share groups among multiple cards, which sometimes caused 
> problems for developers expecting the natural order of messages to be 
> in play, reflecting the visual order in which all controls, even 
> groups, are on top of the card.
>
> So a few versions back a new property was added:  the sharedBehavior. 
> When true this allows us to share a group across multiple cards, and 
> when creating a new card any groups with their sharedBehavior set are 
> automatically placed on new cards.  It's related to the 
> backgroundBehavior, but is not the same thing:
>
> When the backgroundBehavior is set, the sharedBehavior is also set. 
> This should trigger the change you're describing, in which messages 
> are handled by as group with the backgroundBehavior set occur after 
> the card receives them.
>
> But the sharedBehavior can be set by itself, allowing sharing without 
> altering LC's natural message order as reflected by what we see 
> visually on screen:  objects on top of the card get messages before 
> the card does.
>
> So all that said, we might consider what you're seeing to be a bug.
>
> But personally, with more than a decade separating me from the last 
> time I had a machine even capable of running HC, it's been so long 
> since I've thought about the HC-style message order that I never rely 
> on it.  I was very glad when they introduced the sharedBehavior as a 
> way of sharing groups while maintaining the natural, visible order of 
> messages, and when I need messages to occur after the card I generally 
> just put them in the stack or a library.
>
> But there are those who may need the older HC-style message order, and 
> if so that's what the backgroundBehavior is supposed to provide.
>
> If you see a difference between LC and HC with message flow when the 
> backgroundBehavior is set, it may be time to file a bug report.
>