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.
_______________________________________________
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
