groups and background

[J. Landman Gay]

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 
Rev's terminology.

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

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 
"dynamicPaths" property.

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