groups and background
J. Landman Gay
jacque at hyperactivesw.com
Fri Dec 27 17:33:01 EST 2002
Dar Scott <dsc at swcp.com> wrote:
> To me, the most intuitive meaning of "background" is a group used as a
> background, that is, a group with background behavior. Even if I drop
> that notion, we still have an inconsistent use of "background". It
> means one thing when referring to background behavior or backgroundNames
> and two other things in number and group reference. This inconsistency
> is compounded by the inconsistent insertion of the the script of a group
> with background behavior after the card; a control on the card sees it,
> but a control in a group on the card (with no background behavior) or
> the group itself does not.
Some of the behaviors that seem confusing are due to the backward
compatibility with HyperCard stacks. In HyperCard, there can only be a
single background at a time, each of which may contain any number of
cards. Cards are members of backgrounds, never the other way around.
Messages always travel from card to background to stack (then to other
stacks in use,) then to HyperCard. It's a straightforward progression.
Backgrounds are "behind" the cards.
With MC/Rev's introduction of backgrounds as "groups" that can be placed
on a card, the concept of a background as always being "behind" a card
had to be abandoned. This is tough for HC converts to come to grips
with. To a HyperCarder, the concept of backgrounds being ON a card is
weird -- though made somewhat easier if you think of them not as
"backgrounds" but as "groups". This differentiation is reinforced by
To maintain the compatibility with HC, backgrounds/groups with
backgroundBehavior set to true will function as traditional HC
backgrounds. Messages go from card to background to stack. If a card
contains a group with its backgroundBehavior set to true, a new card
created from that card will inherit that "background" just as it does in
In HyperCard "the number of backgrounds" always returns the number of
backgrounds in the stack, since backgrounds are members of the stack.
Revolution's terminology needs to differentiate between all available
groups in the stack, and those which are simply placed on the current
card. "The number of backgrounds" will always refer to the number of
total groups in the stack. "The number of groups" will refer only to the
number of groups that appear (i.e., are "placed") on the current card.
In either case, the backgroundBehavior setting of any particular group
is irrelevant when determining the number.
So: the backgroundBehavior determines only whether the group operates
like a traditional HyperCard background or not, which also affects the
message hierarchy and whether the group is automatically placed on new
cards. The "number of groups" uses the current card as a reference point
and returns the number of groups available on that card. The "number of
backgrounds" uses the stack as the reference point and refers to the
total number of groups in the stack, regardless of whether they are all
on the current card or not.
Now there's the question of the message hierarchy, which gets snarly.
If backgroundBehavior of a group is true, messages behave as though the
group is behind the card, and travel from object to card to group(bg) to
stack. If backgroundBehavior is false, the group operates as though it
is *on* the card rather than behind it, and messages go from object to
group to card to stack.
It gets more complicated if there are several groups on a card. In that
case, once the message goes through the group and reaches the card, it
is then sent to all other groups on the card whose backgroundBehavior is
true -- as though there were, perhaps, several "layers" of backgrounds
behind the card. (At least, I think that's how it works; I'd have to
test it, so take this part with a grain of salt.) Groups with
backgroundBehavior set to false are still considered on "top" of the
card though, and do not receive messages that have been sent from other
groups -- they are out of the loop.
It can get worse. Suppose you have a button in one stack that sends a
message to an object in another stack, which calls a handler in the
second stack's stack script. There is a complex line of messaging that
has to happen, which sometimes should include the second stack's
hierarchy and sometimes doesn't have to. And should handlers farther
down the hierarchy in the first stack receive the message after the
second stack gets it, or should the message stop after it reaches the
second stack? It gets very snarly. SuperCard avoids the whole business
by not allowing this kind of dynamic messaging path at all. HyperCard
has always allowed it. Revolution lets you pick, by setting the
It gets real snaky and I'm glad I didn't have to write the code for it. :)
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
More information about the Use-livecode