Fwd: Quantum tunneling in LiveCode

[Richard Gaskin]

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