Dar Scott <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
