Fwd: Quantum tunneling in LiveCode

Peter Haworth pete at lcsql.com
Tue Mar 3 11:09:23 EST 2015


Thanks for that explanation Richard. I finally get the difference between
sharedBehavior and backgroundBehavior. Seems like sharedBehavior is the one
to use for everything except old HC stacks.

On Tue, Mar 3, 2015, 7:14 AM Richard Gaskin <ambassador at fourthworld.com>
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.
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   ____________________________________________________________________
>   Ambassador at FourthWorld.com                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



More information about the use-livecode mailing list