on 7/21/2000 6:11 AM, David Bovill <[EMAIL PROTECTED]> wrote:
>
> Starting to use groups and they are definitely a major advance, but I guess
> I have to change the architecture of my stack for testing scripts, which
> used to rely on card script passes to background script hierarchy.
>
Here are some scenarios for the message hierarchy. There are some *very*
definite differences in how these things behave, depending upon the origin
of the call.
Control on a Card (Button, etc)
The Card
Group 4 (highest layered group)
Group 3
Group 2
Group 1 (lowest layered group)
Stack
A script on a Card
Group 4 (highest layered group)
Group 3
Group 2
Group 1 (lowest layered group)
Stack
A button in group 2
Group 2
The Card
Stack
> Now with Metacard we have Stacks - cards - groups? So the only way for a
> script on a card to have access to shared scripts is to place them at stack
> level, or perhaps do something unorthodox with the message hierarchy.
No, shared scripts can be done with groups.
> Inserting would seem to allow me to effectively place scripts before the
> target/card or after the "home" scripts???
Insert into Front places the script of the object inserted into prominence
before anything else. Suppose you have a handler "on doittoit" in your
button, and a handler "on doittoit" in the object whose script is set to the
front. Your button's call to "doittoit" will not go the the button's script
first, but to the front script!
So you should only put items in the front that you would never want to
intercept in an object.
Insert into Back places the script of the object inserted into place after
the stack's script. Any handler in a back script can be intercepted by
blocking the message hierarchy with a handler of the same name.
>
> The "Objects" card of the "Concepts & Techniques" stack seems to indicate
> that messages pass through along:
>
> control - group - card - background - stack
>
It depends. See the above examples. I set up a situation in which I had
several controls which would "pass" a handler after receiving it, and would
record the object that received it. That is how I figured this out.
> Since as far as I can tell a group is identical to a background except for
> how it is referred to then I am unclear when a groups/backgrounds script
> will be called?
>
> Does it depend whether the group is on the card??? If it is not will it
> still be intercepted as a background object (as suggested by "Objects" card
> of the "Concepts & Techniques")?
>
A group not on a card does not sit in the hierarchy for that card.
> I think the answer for my stack will be to set the script of an object on a
> group in order to test it, rather than setting the card script. Suppose I'm
> just trying to pin down the concept of "backgrounds" in MetaCard and the
> implications for property inheritance and message passing.
>
> How's this for a definition:
>
> 1) a group is a background placed on a card
> 2) all groups are therefore in this sense backgrounds
> 2b) or alternatively a background is a group not on the current card.
> 3) stacks can contain backgrounds which are not placed on any cards
> 4) backgrounds do not receive messages, only when placed on a card as a
> group.
> 5) try to forget about backgrounds and think of groups and layers
>
I see where you are going here. I'm not sure all of this is technically
correct, but it is a start.
I have a one-page stack with the message hierarchy test on it. If you want
it, send a request off list.
Cheers,
Raymond
Archives: http://www.mail-archive.com/metacard%40lists.best.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
