Groups as background
Hi, I have a stack with 3 card that have a group background as menu for all the cards. Now I modified the group and add some cards more. All the cards have different groups and the changes aren't replicated. Why? How solve this? recreate again all the cards with delete and copypaste? Salut, Josep -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Groups-as-background-tp3048672p3048672.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Groups as background
Hi Josep, Hi, I have a stack with 3 card that have a group background as menu for all the cards. Now I modified the group and add some cards more. All the cards have different groups and the changes aren't replicated. Why? How solve this? recreate again all the cards with delete and copypaste? no copy paste neccessary! Go to the card(s) here you want to place your group and choose menu Object - Place group -Name of your group here... That's it :-) Salut, Josep Best Klaus -- Klaus Major http://www.major-k.de kl...@major.on-rev.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Groups as background
Make sure that the background behavior (behaves like a background) of the group is true, so when you add additional cards the group will appear there. You only need to do this once. The engine will take care of this forever. Craig Newman ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Groups as background
Oh... thanks,... has already started going crazy .. I did not know you could do this way. :) Salut, Josep -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Groups-as-background-tp3048672p3048928.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
On Monday, January 6, 2003, at 02:06 PM, Dar Scott wrote: so there IS a RunRev specific reason to use the the background concept. I think the double the typo is significant. I think we run into trouble in thinking of the background concept. There seems to be two, even though both seem to have a basis in history. There is background in the sense of backgroundBehaviour and background in the sense of thinking of groups belonging to the stack. The backgroundbehaviour path modification, automatic placement and backgroundNames() are related to the first concept. The rest of the uses of the word background seem to be related to the second, though there may be a few for the first concept that I missed. For example I just learned that openBackground is sent only for groups with backgroundBehavior set to true, so it belongs with the first concept of background. I wonder if there are more. Dar Scott Hast thou not poured me out and curdled me like cheese? -- Job Poets have been mysteriously silent on the subject of cheese. -- G. K. Chesterton We have seen thee, queen of cheese, Lying quietly at your ease, Gently fanned by evening breeze Thy fair form no flies dare seize. -- James McIntyre Society... We meet at meals three times a day, and give each other a new taste of that old musty cheese that we are. -- Henry David Thoreau Many's the long night that I've dreamed of cheese--toasted, mostly. -- Robert Louis Stevenson Politics, religion and cheese are all off topic. -- Heather Williams ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
"J. Landman Gay" [EMAIL PROTECTED] wrote: if the number of cds in this bg 1then answer "I'm shared." without evoking the "background" concept? the number of cds to which group "foo" is attached.Actually, my example does invoke the "background" concept by referring to "this bg". You can refer to any background; for example, "the number of cards in bg foo". The critical distinction is that if you want the number of cards that a group is placed on, you need to refer to the group as a background the way HyperCard does. Referring to a "group" assumes the referent is the card and you get back only the groups placed on the current card. Referring to "background" assumes the referent is the stack the way HyperCard does it. Though the groups themselves are the same objects either way, the point of reference changes depending on the terminology in the script. ah ha! so there IS a RunRev specific reason to use the the "background" concept.[EMAIL PROTECTED] http://www.erikhansen.orgDo you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now
Re: Re[7]: groups and background
On Monday, January 6, 2003, at 01:31 PM, erik hansen wrote: so there IS a RunRev specific reason to use the the background concept. I think the double the typo is significant. I think we run into trouble in thinking of the background concept. There seems to be two, even though both seem to have a basis in history. There is background in the sense of backgroundBehaviour and background in the sense of thinking of groups belonging to the stack. The backgroundbehaviour path modification, automatic placement and backgroundNames() are related to the first concept. The rest of the uses of the word background seem to be related to the second, though there may be a few for the first concept that I missed. Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
I wouldn't say it has _no_ benefit, just that the behavior change of copying groups to new cards can be done in another way. As far as I understand it, the backgroundBehavior property is for HyperCard compatibility, not feature-enrichment. The message path modifying aspect would be harder (impossible?) to replicate, but you could do something like it by inserting the script of the group in back. It wouldn't be in the same place in the path, though. On Saturday, January 4, 2003, at 11:18 PM, Mark Swindell wrote: So, if my blurry eyes are reading between the lines... are you sort of implying that background behavior may not be of particular benefit. It's sure starting to seem that way. Good tip on the copy this cd to this stack. Does the very same thing as background behavior, only for all elements. regards, Geoff Canyon [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
"J. Landman Gay" [EMAIL PROTECTED] wrote: Now, how do I find out if a group is shared or not?Piece of cake:if the number of cds in this bg 1then answer "I'm shared." without evoking the "background" concept? the number of cds to which group "foo" is attached.[EMAIL PROTECTED] http://www.erikhansen.orgDo you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now
Re: Re[7]: groups and background
On Monday, January 6, 2003, at 12:28 AM, erik hansen wrote: the number of cds to which group foo is attached. Script compile error: Error description: Commands: missing ',' Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
ifyou are NOT concerned with HC compatability, is there any reason to use backgroundBehavior? TIA.[EMAIL PROTECTED] http://www.erikhansen.orgDo you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now
Re: Re[7]: groups and background
ifyou are NOT concerned with HC compatability, is there any reason to use backgroundBehavior? TIA.[EMAIL PROTECTED] http://www.erikhansen.orgDo you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now
Re: Re[7]: groups and background
on 1/4/03 6:29 PM, erik hansen at [EMAIL PROTECTED] wrote: if you are NOT concerned with HC compatability, is there any reason to use backgroundBehavior? TIA. If you want to make a new card which has elements of the current card you are on, those elements need to have backgroundbehavior set to true. If you want to put a script behind the card and before the stack, having background behavior puts the script in that position in the hierarchy. (At least I think this is so. Someone may correct me.) There are probably other reasons, too. Mark ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
On Saturday, January 4, 2003, at 07:56 PM, Mark Swindell wrote: If you want to put a script behind the card and before the stack, having background behavior puts the script in that position in the hierarchy. (At least I think this is so. Someone may correct me.) The group script is seen after the card and before the stack for some targets and not for others. Only controls directly on the card and the card itself that has such a group placed on it see the script behind the card. Groups (with or without background behavior) and controls in groups do not see the script. Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
You can: copy this cd to this stack which gets you all the controls of the card, grouped or not. You could also get the names of the groups on the current card and place the appropriate ones (see the recent discussions on placeable groups) on a new card that you create. On Saturday, January 4, 2003, at 06:56 PM, Mark Swindell wrote: on 1/4/03 6:29 PM, erik hansen at [EMAIL PROTECTED] wrote: if you are NOT concerned with HC compatability, is there any reason to use backgroundBehavior? TIA. If you want to make a new card which has elements of the current card you are on, those elements need to have backgroundbehavior set to true. I hope this helps. Feel free to contact me if you have any further questions. regards, Geoff Canyon Revolution Support -- Geoff Canyon [EMAIL PROTECTED] http://www.runrev.com/ Runtime Revolution Limited - The Solution for Software Development Tel: +44 (0) 870 747 1165. Fax: +44 (0)1639 830 707. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
on 1/4/03 10:56 PM, Geoff Canyon at [EMAIL PROTECTED] wrote: You can: copy this cd to this stack which gets you all the controls of the card, grouped or not. You could also get the names of the groups on the current card and place the appropriate ones (see the recent discussions on placeable groups) on a new card that you create. On Saturday, January 4, 2003, at 06:56 PM, Mark Swindell wrote: on 1/4/03 6:29 PM, erik hansen at [EMAIL PROTECTED] wrote: if you are NOT concerned with HC compatability, is there any reason to use backgroundBehavior? TIA. If you want to make a new card which has elements of the current card you are on, those elements need to have backgroundbehavior set to true. I hope this helps. Feel free to contact me if you have any further questions. regards, Geoff Canyon Revolution Support So, if my blurry eyes are reading between the lines... are you sort of implying that background behavior may not be of particular benefit. It's sure starting to seem that way. Good tip on the copy this cd to this stack. Does the very same thing as background behavior, only for all elements. Thanks, Mark ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
On Saturday, December 28, 2002, at 03:15 PM, Dar Scott wrote: A group may have its backgroundBehavior property set to true. Such a group introduces interesting paths on any card it is on. This group is also placed on new cards under some conditions. The card/stack property backgroundNames lists all groups with this property set to true for the specified card or stack. BackgroundNames is a property of a stack, but not of a card. Groups may be shared. The number of backgrounds (of a stack) is the number of sharable groups in the stack; shared groups are counted only once. (The number of backgrounds of a card is 0.) All groups are sharable except nested groups. The property groupNames is a card property that lists all sharable groups on the card. There is no such property for stacks. Everything here is right. I do think sharable is unnecessarily confusing the issue for the sake of brevity. _All_ groups are sharable, in the sense that they can appear on more than one card. Groups contained in other groups appear on whatever cards their parent groups appear on. You call them nested groups. I think of them as subgroups, although that term has no official standing. By sharable, you might also be referring to the (more verbose) concept of able to be placed onto a card, which rules out nested/subgroups. The number of groups [of a specified card] is the total number of groups on the card including shared and nested. The number of groups of a stack is the total number of groups on the current card. Shared groups are counted just once. Correct. The expression group groupref refers to a group on the current or specified card. The expression background groupref refers to any group in the current or specified stack (including nested groups). The layer number (if used) for the background reference refers to the creation order. Correct. regards, Geoff Canyon [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
--- Rob Cozens [EMAIL PROTECTED] wrote: You mean you can place a group across mutiple cards without having the backgroundBehavior set? One can place any group on any existing card. BackgroundBehavior just determines whether the group is automatically placed on each new card that is added to the stack Close, but not entirely true. It also determines its place in the message path: before or behind the card. If I got that right, that is, because this whole thread is making my head hurt. Jan Schenkel. = As we grow older, we grow both wiser and more foolish at the same time. (La Rochefoucauld) __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
on 12/29/02 7:39 AM, Rob Cozens at [EMAIL PROTECTED] wrote: You mean you can place a group across mutiple cards without having the backgroundBehavior set? One can place any group on any existing card. BackgroundBehavior just determines whether the group is automatically placed on each new card that is added to the stack Provided the group with backgroundBehavior exists on the card from which a new card is created. If I have a group A on cd 1 which has backgroundBehavior set to true, and a group B on cd 2 with its backgroundBehavior set to true, when I am on cd 1 and create a new card (a new cd 2) it will have group A on it, but not group B. When I go to cd 3 (which was cd 2 and contains group B) and create a new card, cd 4 (the new card) will contain group B, but not group A. Mark ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
On Sunday, December 29, 2002, at 02:43 AM, Geoff Canyon wrote: A group may have its backgroundBehavior property set to true. Such a group introduces interesting paths on any card it is on. This group is also placed on new cards under some conditions. The card/stack property backgroundNames lists all groups with this property set to true for the specified card or stack. BackgroundNames is a property of a stack, but not of a card. But it works on Rev 1.1.1 on OS X. I get different lists for the backgroundNames of this stack and the backgroundNames of this card. Groups may be shared. The number of backgrounds (of a stack) is the number of sharable groups in the stack; shared groups are counted only once. (The number of backgrounds of a card is 0.) All groups are sharable except nested groups. The property groupNames is a card property that lists all sharable groups on the card. There is no such property for stacks. Everything here is right. I do think sharable is unnecessarily confusing the issue for the sake of brevity. _All_ groups are sharable, in the sense that they can appear on more than one card. Groups contained in other groups appear on whatever cards their parent groups appear on. You call them nested groups. I think of them as subgroups, although that term has no official standing. I think subgroup is a better name. Nesting is more a relationship among groups than an attribute of a group. Another name might be embedded group. I'll run with subgroup. By sharable, you might also be referring to the (more verbose) concept of able to be placed onto a card, which rules out nested/subgroups. Yes. I was going to write placeable, but I kept spelling it placable and that didn't look right. In light of your comment on sharable, I'd replace it with placeable. But, dropping the qualifier is not right because that would include the subgroups. (In my stacks, most groups are subgroups.) So I revise this: Groups may contain groups. Those contained groups are subgroups. All groups may be shared. A group placed on a card is not a duplicate but is the same group shared by some number of cards. Subgroups may only be shared by the root parent group being placed on a card. Groups that are not subgroups may be placed on cards. The number of backgrounds of a stack is the number of placeable groups in the stack; groups are counted only once. (The number of backgrounds of a card is 0.) The property groupNames is a card property that lists all placeable groups on the card. There is no such property for stacks. A group may be removed from all cards but still exist in the stack. Getting the owner of such a stack creates an error. The cards of a group may be referenced. Expressions such as card 1 of this background or the number of cards in this background may be used. Maybe this is better. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
On Sunday, December 29, 2002, at 12:26 PM, Dar Scott wrote: A group may be removed from all cards but still exist in the stack. Getting the owner of such a stack creates an error. Yikes! The owner is the stack. And the stack is next in its path. I had somehow corrupted the stack with some group experiments and was getting errors. Now I don't. That same test showed the group as not placeable. I'll try to recreate this. But, it looks like groups on on cards are placeable and have owners, when things are working right. Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
On Saturday, December 28, 2002, at 04:19 AM, Geoff Canyon wrote: First, forget about the backgroundBehavior property. It has nothing to do with the use of the terms background and group Well, one might assume that backgrounds is the plural of background and this is not the case in the backgrounds. Also, you might say forget, but that does not address the issue of any newbie who reads about setting the backgroundBehavior to true and thinks he is creating a background. Yeah, I was perhaps adding to the confusion in calling groups with backgroundBehavior set to true backgrounds; I was thinking of background as stack group as aberrant. What word would you suggest for a group or background whose backgroundBehavior is true. Are we to use that long phrase? What word would you suggest for a group whether referenced as a group or as a background? Just realized I haven't answered the actual question. The number of backgrounds on both cards is 2 because it's relative to the stack: the number of backgrounds is _always_ the same across all the cards of a stack. Yes. I noticed that and that is a good thing. It's 2 rather than 3 because groups that are nested in other groups don't count as backgrounds. That is what I suspected, but I didn't run the tests, so I didn't mention it above. Now this is just weird. And I claim it is confusing. The only way I can think of to get the real number of backgrounds (in this sense, that is, the total number of groups in a stack including nested groups) is to iterate through them until an error occurs. The number of groups on card 1 is 3 because all three groups are on that card. The number of groups on card 2 is 1 because there is only one group -- c -- placed on it. Right. Thanks for the info on what the number of backgrounds actually counts. I guess that was a question. But the bigger question (the one I had in mind in illustrating that background is confusing) is how to think about and how to communicate about these concepts. The related question that perhaps should be asked is whether we should ask for or suggest that this whole area is simplified, cleaned up and made more powerful as well as easier to understand. Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
What word would you suggest for a group or background whose backgroundBehavior is true. Are we to use that long phrase? I've always used the term shared groups. What word would you suggest for a group whether referenced as a group or as a background? A group. Keep in mind that the whole concept of a background is only there for HyperCard compatibility. The object type is group, regardless of what its properties are. So you need to think of it as groups that are either shared with other cards, or not. This is like the sharedText property of a field or the sharedHilite of a button; just because it is sharing a property is no reason to call it by some other name than its given object type. Just my $0.02 that has kept me sane over the years... Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Fw: Re[7]: groups and background
One more thing... if MC/Rev had called this property sharedContents rather than backgroundBehavior I think it could have cleared up a lot of the confusion... Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ - Original Message - From: Ken Ray [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, December 28, 2002 1:06 PM Subject: Re: Re[7]: groups and background What word would you suggest for a group or background whose backgroundBehavior is true. Are we to use that long phrase? I've always used the term shared groups. What word would you suggest for a group whether referenced as a group or as a background? A group. Keep in mind that the whole concept of a background is only there for HyperCard compatibility. The object type is group, regardless of what its properties are. So you need to think of it as groups that are either shared with other cards, or not. This is like the sharedText property of a field or the sharedHilite of a button; just because it is sharing a property is no reason to call it by some other name than its given object type. Just my $0.02 that has kept me sane over the years... Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
Ken Ray wrote: One more thing... if MC/Rev had called this property sharedContents rather than backgroundBehavior I think it could have cleared up a lot of the confusion... Or even just shared, and mark the token background as depricated and included only for compatibility with less flexible systems. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge 2.1: Publish any database on any site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Fw: Re[7]: groups and background
At 11:07 AM -0800 12/28/02, Ken Ray wrote: One more thing... if MC/Rev had called this property sharedContents rather than backgroundBehavior I think it could have cleared up a lot of the confusion... But that would imply that groups with backgroundBehavior turned off aren't shared between cards, which isn't the case. -- Jeanne A. E. DeVoto ~ [EMAIL PROTECTED] Runtime Revolution Limited - The Solution for Software Development http://www.runrev.com/ ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
Jeanne A. E. DeVoto wrote: At 11:07 AM -0800 12/28/02, Ken Ray wrote: One more thing... if MC/Rev had called this property sharedContents rather than backgroundBehavior I think it could have cleared up a lot of the confusion... But that would imply that groups with backgroundBehavior turned off aren't shared between cards, which isn't the case. Good catch. You mean you can place a group across mutiple cards without having the backgroundBehavior set? Cool. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge 2.1: Publish any database on any site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
On Saturday, December 28, 2002, at 01:37 PM, Richard Gaskin wrote: Jeanne A. E. DeVoto wrote: At 11:07 AM -0800 12/28/02, Ken Ray wrote: One more thing... if MC/Rev had called this property sharedContents rather than backgroundBehavior I think it could have cleared up a lot of the confusion... But that would imply that groups with backgroundBehavior turned off aren't shared between cards, which isn't the case. Good catch. You mean you can place a group across mutiple cards without having the backgroundBehavior set? Cool. Wow! I'm going to try this. This looks interesting. Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
On Saturday, December 28, 2002, at 12:24 PM, Richard Gaskin wrote: One more thing... if MC/Rev had called this property sharedContents rather than backgroundBehavior I think it could have cleared up a lot of the confusion... Or even just shared, and mark the token background as depricated and included only for compatibility with less flexible systems. Would the backgrounds, then be the sharedGroups? Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
on 12/28/02 12:37 PM, Richard Gaskin at [EMAIL PROTECTED] wrote: But that would imply that groups with backgroundBehavior turned off aren't shared between cards, which isn't the case. Good catch. You mean you can place a group across mutiple cards without having the backgroundBehavior set? Cool. I thought backgroundbehavior only referred to a group's being included when a new card was created. Mark http://www.runrev.com/revolution/developers/articles/tipoftheweek/5.html explains: There are two special group features: background behavior (that allows you to make groups act more like backgrounds) and radio behavior. If you group objects to create a group, then make a new card, that group will not appear on the new card. If you go to the properties for a group and check Background Behavior, that group will then appear on all new cards so long as it was present on the visible card when you made the new card. This is how you make a group act like a HyperCard background. You can even group a single object if you need to make it act this way. If you have made a group and then want to add it to other cards later, the easiest way is to use the Application Overview. If you select your stack in the overview and toggle the wide display, you will see a set of tabs along the top of the right section. Click on the second tab along - Groups. Now you should see a list of all groups present in your stack. If you see components of a particular group instead, click on the sliding button at the bottom. When you select a group, you can use the Place Remove buttons to adjust which cards you want to show this group. You can also use the Object menu to place remove groups but this doesn't allow you to place groups on every card at once and will not list groups contained within other groups. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Fw: Re[7]: groups and background
At 11:07 AM -0800 12/28/02, Ken Ray wrote: One more thing... if MC/Rev had called this property sharedContents rather than backgroundBehavior I think it could have cleared up a lot of the confusion... But that would imply that groups with backgroundBehavior turned off aren't shared between cards, which isn't the case. Good point. Interestingly enough, in MC, only groups that have the backgroundBehavior property can be placed through the interface (in fact, the menu item is Backgrounds...) - after placement, however, you can turn off the backgroundBehavior property and the contents are still shared between the cards. This is probably why Rev's menu item is Place Group. Note though that once a group is created, its backgroundBehavior property is FALSE. As soon as you place it on another card via Place Group, however, Rev automatically sets the backgroundBehavior property of the group to TRUE. The combination of these two methods are probably where Richard and I (and perhaps others) assumed that you *needed to have* the backgroundBehavior property turned on in order to share content. It does seem odd, though, that buttons can share their hilite through a property, fields can share their text through a property, but groups share their contents through being placed - no property to set here, it seems. Of course the docs state that the backgroundBehavior property has nothing to do with content sharing, but is specifically to put such a group in the message-passing hierarchy behind cards, and to have it automatically placed on new cards as they're created. But I think the confusion is over the content-sharing aspects of a group, and not the message hierarchy issues. Hmm... Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
On Saturday, December 28, 2002, at 01:50 PM, Dar Scott wrote: Good catch. You mean you can place a group across mutiple cards without having the backgroundBehavior set? Cool. Wow! I'm going to try this. This looks interesting. I tried this. Sure enough a group was placed. But I could not open the properties for it or anything else. A little later it disappeared. This happened twice. (OS X, Rev 1.1.1) Am I doing something wrong or is there a problem with this method? Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
At 12:46 PM -0800 12/28/02, Dar Scott wrote: On Saturday, December 28, 2002, at 12:06 PM, Ken Ray wrote: Keep in mind that the whole concept of a background is only there for HyperCard compatibility. Well, isn't a shared group useful in its own right. Sure, but a group's backgroundBehavior doesn't determine whether it's shared. It determines two things: - whether the group is automatically placed on new cards when you start from a card that has the group; - whether the group is in the message path of cards it's placed on Whether a group is shared depends on whether it's on multiple cards, not on its backgroundBehavior setting. -- Jeanne A. E. DeVoto ~ [EMAIL PROTECTED] Runtime Revolution Limited - The Solution for Software Development http://www.runrev.com/ ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Fw: Re[7]: groups and background
On Saturday, December 28, 2002, at 01:59 PM, Ken Ray wrote: This is probably why Rev's menu item is Place Group. Note though that once a group is created, its backgroundBehavior property is FALSE. As soon as you place it on another card via Place Group, however, Rev automatically sets the backgroundBehavior property of the group to TRUE. This is the case for placing from the message box, too, not just the menu. The combination of these two methods are probably where Richard and I (and perhaps others) assumed that you *needed to have* the backgroundBehavior property turned on in order to share content. I assumed that. I was sure I read it. I first started back in March and came with no preconceptions, but somehow I got the idea. It does seem odd, though, that buttons can share their hilite through a property, fields can share their text through a property, but groups share their contents through being placed - no property to set here, it seems. Yikes. More assuming. I had assumed all that sharing had something to do with shared groups and put off considering what it was until later. Of course the docs state that the backgroundBehavior property has nothing to do with content sharing, but is specifically to put such a group in the message-passing hierarchy behind cards, and to have it automatically placed on new cards as they're created. Oh, good. If I could read... But I think the confusion is over the content-sharing aspects of a group, and not the message hierarchy issues. At least. Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
On Saturday, December 28, 2002, at 02:07 PM, Dar Scott wrote: Sure enough a group was placed. But I could not open the properties for it or anything else. A little later it disappeared. This happened twice. (OS X, Rev 1.1.1) Am I doing something wrong or is there a problem with this method? I found the problem. I was placing a nested group. Both the engine and the IDE have trouble with this. I did place a group and then set the backgroundBehavior to false as Key suggested. It was false on other cards. I edited the script by adding a comment. The edited script showed up on other cards. I moved some controls. They moved everywhere. Cool. It looks shared. Now the backgroundNames (which I had earlier in error called the backgrounds--sorry) returns a list of groups with backgroundBehavior set to true. It is not the list of shared groups as I speculated. And it is not the list of groups in a stack, nor is it the list of groups directly on cards in the stack. Now, how do I find out if a group is shared or not? Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
On Saturday, December 28, 2002, at 08:58 AM, Dar Scott wrote: I got numbers that are not consistent with this. (see my mail yesterday) I think the number of backgrounds refers to total number of groups directly on or placed on cards of the stack. I suspect that nested groups are not counted. I will have to run more tests to be sure. This is exactly correct. I agree that it might be a bit confusing, but I think the rationale is this: a background is a group that can be placed onto a card. A nested group cannot be placed onto a card, except if its owner is placed onto the card (which will include any nested groups). A group that is enclosed in another cannot be used as a background, and therefore is not a background. On Saturday, December 28, 2002, at 09:34 AM, Dar Scott wrote: I apologize. I didn't mean to ignore your suggestion. I was aware of the behavior of there is a group and there is a background. I went on to show that the number of had the same problems and both were not consistent with the groups of and the backgrounds of. I don't think there is a the groups of construct. You can get the groupnames of a card, and the backgroundnames of a stack. But are people confused by this? I would guess that some people are under the impression that there is a background means that there is a group with background behavior set somewhere in the stack by that name. That would not be the case. You're right above. there is a background means there is a non-enclosed group of that name somewhere in the stack. I would guess that some people are under the impression that there is a background means that there is a group somewhere in the stack by that name. But, it doesn't work that way on my system. there is a background _does_ mean there is a group somewhere in the stack by that name. However, the reverse is not true: there can be a group named bob in a stack, and 'there is a background bob' could still return false. This would be the case if group bob were enclosed in (a part of) group sally I would guess that some might think that if 'there is a group alpha' is true, then 'there is a background alpha' is true. I see counterexamples. Same as above. If group alpha is part of group omega then group alpha cannot be a background -- it cannot be placed onto a card. I would guess that some might expect the number of lines in the backgrounds to be the same as the number of backgrounds. This is not the case. If you're referring to the backgroundNames or the backgroundIDs, you're right and I agree with you. The backgroundNames and backgroundIDs return a subset of the backgrounds: the ones that have the backgroundBehavior set to true. I agree that's confusing. But you can easily write: function myBackgroundNames() put empty into tReturnList repeat with i = 1 to the number of backgrounds of this stack put the short name of background i cr after tReturnList end repeat return tReturnList end myBackgroundNames I would guess that some might think that 'there is a background alpha' is the same as 'alpha is among the lines of the backgrounds'. I would guess otherwise. See above. This is in addition to confusion areas. We have these three (at least): 1) The use of background in background behavior vs. background in some subset of groups associated with a stack. I agree that backgroundBehavior can be misleading. But it would be misleading to use a name that didn't include background since its function is to make groups/backgrounds work like backgrounds in HyperCard. Maybe change it to HCBackgroundBehavior ;-) 2) The inconsistent use of background in the subsets of groups associated with a stack. (As described above) 3) The inconsistent path for groups that do not have background behavior set. The inconsistency is the result of attempted HyperCard compatibility. I never set backgroundBehavior to true, so I'm not too familiar with any issues it might cause. Somewhere along the way you asked what others call these things. I always think of them as groups. I only use the term background when I'm placing one onto a card. I think Ken pointed out the syntax supports this as well. If you put the name of a background, you'll get group whatever regards, Geoff Canyon [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
On Saturday, December 28, 2002, at 03:07 PM, Geoff Canyon wrote: This is exactly correct. I agree that it might be a bit confusing, but I think the rationale is this: a background is a group that can be placed onto a card. A nested group cannot be placed onto a card, except if its owner is placed onto the card (which will include any nested groups). A group that is enclosed in another cannot be used as a background, and therefore is not a background. I understand that rational. That helps a lot. I don't like the name, but I understand. Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
Let's see if I got this right. * A group may have its backgroundBehavior property set to true. Such a group introduces interesting paths on any card it is on. This group is also placed on new cards under some conditions. The card/stack property backgroundNames lists all groups with this property set to true for the specified card or stack. Groups may be shared. The number of backgrounds (of a stack) is the number of sharable groups in the stack; shared groups are counted only once. (The number of backgrounds of a card is 0.) All groups are sharable except nested groups. The property groupNames is a card property that lists all sharable groups on the card. There is no such property for stacks. The number of groups [of a specified card] is the total number of groups on the card including shared and nested. The number of groups of a stack is the total number of groups on the current card. Shared groups are counted just once. The expression group groupref refers to a group on the current or specified card. The expression background groupref refers to any group in the current or specified stack (including nested groups). The layer number (if used) for the background reference refers to the creation order. * Is this right? Is this complete? Is the word group or background used in any other way? Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
On Sat, 28 Dec 2002 11:53:40, Dar Scott wrote: The related question that perhaps should be asked is whether we should ask for or suggest that this whole area is simplified, cleaned up and made more powerful as well as easier to understand. I liked the approach to this problem used in OMO (Oracle Media Objects). They had background - with same behavior and message passing hierarchy as in HyperCard And they had background groups and card groups. No confusion, for me personally, unlike I had and still have in MC/Rev scheme. Best regards Tariel Gogoberidze ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
On Saturday, December 28, 2002, at 01:37 PM, Dar Scott wrote: Now, how do I find out if a group is shared or not? Piece of cake: if the number of cds in this bg 1 then answer I'm shared. -- 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
Re: Re[7]: groups and background
On Saturday, December 28, 2002, at 06:34 PM, J. Landman Gay wrote: On Saturday, December 28, 2002, at 01:37 PM, Dar Scott wrote: Now, how do I find out if a group is shared or not? Piece of cake: if the number of cds in this bg 1 then answer I'm shared. Cool! I am impressed. I even get a 0 for backgrounds not on any cards. Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
Dar Scott wrote 02.12.26 00:08 PM$B!'(B (B (B(I find the artifact of a katakana character (yu?) in the quoted (Bmaterial interesting.) (B (BSorry, I made a mistake. (BAnd you answered it correctly. It is right 'yu' ;-) (B (B (BBoth the scripting language and the documentation seem to be a (Blittle free in interchanging these; no doubt those who have grown up (Bwith cards can tell from context, but it slows me down. (B (BYes, It is related to the thing that I sent in this topic first. (B (B (BIt doesn't help with messages sent to (Bthe background, or to controls owned by by groups within the background. (B (BI'm about to make a stack that can use backgrounds. Unfortunately, with (Bthe multicard placement comes the inconsistent message path. (B (BI understood. This problem is unexpectedly difficult... (B (B (BUDI ([EMAIL PROTECTED] (Bhttp://member.nifty.ne.jp/UDI/ (B___ (Buse-revolution mailing list ([EMAIL PROTECTED] (Bhttp://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
On Friday, December 27, 2002, at 08:32 AM, Rob Cozens wrote: I believe the distinction is background can refer to any group in a stack, whereas group can refer only to groups on the current card. Ah. I have been using background to mean a group with background behavior. Now, now this is twice as confusing. Dar ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
I believe the distinction is background can refer to any group in
a stack, whereas group can refer only to groups on the current
card.
Ah. I have been using background to mean a group with background
behavior. Now, now this is twice as confusing.
If I am correct, put there is a background/group
[groupName/groupId] should yield different results depending on
whether the group is placed on the current card.
I could test this for you, Dar; but it was your question...and
self-discovery is much more meaningful, don't you think? :{`)
--
Rob Cozens
CCW, Serendipity Software Company
http://www.oenolog.com/who.htm
And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee.
from The Triple Foole by John Donne (1572-1631)
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
On Friday, December 27, 2002, at 09:57 AM, Rob Cozens wrote: I believe the distinction is background can refer to any group in a stack, whereas group can refer only to groups on the current card. Ah. I have been using background to mean a group with background behavior. Now, now this is twice as confusing. If I am correct, put there is a background/group [groupName/groupId] should yield different results depending on whether the group is placed on the current card. I could test this for you, Dar; but it was your question...and self-discovery is much more meaningful, don't you think? I think this illustrates my point. By using the word place, I assume you mean groups with background behavior. Are you saying that one would normally make all groups have background behavior. Mine rarely do. It gets worse. I have a stack with two cards. Card one has three groups a, b and c. Group a is nested in group b. Group c has background behavior. Card two has c placed on it. Results from number of: Card 1 Card 2 groups 3 1 backgrounds2 2 So, the number of groups returns something I understand. But, the number of backgrounds is not clear. I would have thought it would return 1 in both cases, since there is only one group with background behavior, or return 3 in both cases since there are 3 groups (with or without background behavior) in the stack. Though the number of backgrounds is 2, I can refer to background n, for n=1,2,3 and refer to each of the groups in the stack. Also groupNames of card 1 does not include group a and backgroundNames of the stack has only the group with the background behavior. So, we have three different counts for background. Consider the TD for place. It says that when you use create card any groups on the current card are automatically placed on the new card. This is not so. Only those groups with background behavior are placed. I'm not sure whether this is a typo or an assumption that, of course, groups have background behavior. 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. This inconsistency complicates some programming, but the greater cost is in the learning curve. Let's see, do I want the number of backgrounds or the number of lines of backgroundNames? Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
I could test this for you, Dar; but it was your question...and
self-discovery is much more meaningful, don't you think?
Aw shucks, Dar...It worked for Tom Sawyer. Guess you'll probably
pass up the wonderful opportunity for fence painting I was about to
offer you too. :{~)
Anyway, I opened the Rev version of OenoLog to a card that did not
contain the group, Product Code.
From the message box:
there is a group Product Code -- false
there is a background Product Code -- true
--
Rob Cozens
CCW, Serendipity Software Company
http://www.oenolog.com/who.htm
And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee.
from The Triple Foole by John Donne (1572-1631)
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
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
Re: Re[7]: groups and background
(BOn Wednesday, December 25, 2002, at 01:01 AM, UDI wrote: (B (B -- (B If you want a handler in a group$B%f(Bs script to affect only the objects in (B the group, place the following statement at the beginning of the (B handler: (B (Bif the owner of the target is not me then pass message (B (B This filters out any objects that are not part of the group. (B -- (B (B(I find the artifact of a katakana character (yu?) in the quoted (Bmaterial interesting.) (B (BI think this help would be clearer if it said "background" rather than (B"group". Both the scripting language and the documentation seem to be a (Blittle free in interchanging these; no doubt those who have grown up (Bwith cards can tell from context, but it slows me down. (B (BThis idea is a good one. However, I think it applies only to controls (Bdirectly owned by the background. It doesn't help with messages sent to (Bthe background, or to controls owned by by groups within the background. (B (BI'm about to make a stack that can use backgrounds. Unfortunately, with (Bthe multicard placement comes the inconsistent message path. (B (BDar Scott (B (B___ (Buse-revolution mailing list ([EMAIL PROTECTED] (Bhttp://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[6]: groups and background
On Friday, December 20, 2002, at 12:34 AM, UDI wrote: All bg is unrelated, and control is included in bg3: bg4 ( no message ) control -- bg3 -- stack bg2 ( no message ) bg1 ( no message ) card ( no message ) bg3 is included bg2, and control is included in bg3: bg1 ( no message ) control -- bg3 -- bg2 -- stack bg4 ( no message ) card ( no message ) My tests are similar. I pass mouseUp and I have only one background. But, I get the card included in my results. Could you have left theEvent out of the card script? Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
On Friday, December 20, 2002, at 12:50 AM, UDI wrote: Sorry, I made a mistake. Then ignore my comments that crossed in the mail. All bg is unrelated, and control on card: control -- card -- bg4 | bg3 | bg2 v bg1 -- stack All bg is unrelated, and control is included in bg3: bg4 ( no message ) control -- bg3 -- card -- stack bg2 ( no message ) bg1 ( no message ) I guess the idea is that if a control is in a group, even a background group, it is in the environment of that group or groups. But if the control is directly on the card it is in the environment of the card as modified by background groups. Even so, I am not able to rationalize why groups on the card or nested groups and controls within those do not have a message path like the first case. Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re[9]: groups and background
Dar Scott wrote 02.12.20 01:18 AM$B!'(B (B (B All bg is unrelated, and control on card: (Bcontrol -- card -- bg4 | (B bg3 | (B bg2 v (B bg1 -- stack (B (B All bg is unrelated, and control is included in bg3: (Bbg4 ( no message ) (Bcontrol -- bg3 -- card -- stack (Bbg2 ( no message ) (Bbg1 ( no message ) (B (BI guess the idea is that if a control is in a group, even a background (Bgroup, it is in the environment of that group or groups. But if the (Bcontrol is directly on the card it is in the environment of the card as (Bmodified by background groups. (B (BEven so, I am not able to rationalize why groups on the card or nested (Bgroups and controls within those do not have a message path like the (Bfirst case. (B (B (BAbout the first case, I think for compatibility with Hypercard. (B (BIF it is so, (BRather the second case includes a problem. It is NOT right that a (Bmessage of control in a background is carried to a card. (B (BBUT, (BWe have to recognize this. A thing having both of perfect-logical and (BHyperCard-compatibile is impossible. (B (B (BUDI ([EMAIL PROTECTED] (Bhttp://member.nifty.ne.jp/UDI/ (B___ (Buse-revolution mailing list ([EMAIL PROTECTED] (Bhttp://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
All bg is unrelated, and control on card: control -- card -- bg4 | bg3 | bg2 v bg1 -- stack All bg is unrelated, and control is included in bg3: bg4 ( no message ) control -- bg3 -- card -- stack bg2 ( no message ) bg1 ( no message ) I guess the idea is that if a control is in a group, even a background group, it is in the environment of that group or groups. But if the control is directly on the card it is in the environment of the card as modified by background groups. Even so, I am not able to rationalize why groups on the card or nested groups and controls within those do not have a message path like the first case. Dar Scott It seems that the first case uses the logic that backgrounds are behind the card, whereas the second case seems to consider backgrounds as groups placed on a card (so the background is in front of the card so do speak. My guess is that the bg attribute of a grp is ignored in this case. I would expect the second behavior to be for normal groups. They are on the card and the message should pass from them to the card. However, bg groups should be behind the card and the message passing should skip the card. My 0.02 cents Robert Brenstein ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[7]: groups and background
On Friday, December 20, 2002, at 05:23 AM, Robert Brenstein wrote:
It seems that the first case uses the logic that backgrounds are behind
the card, whereas the second case seems to consider backgrounds as
groups placed on a card (so the background is in front of the card so
do speak. My guess is that the bg attribute of a grp is ignored in this
case.
The problem is really the third case. If the groups are not
backgrounds, they are treated as such in the message path as far as
whether the backgrounds are after the card.
Consider this card: card{ grpA( btn1 ), btn2, bgB( btn3 ) }
Background bgB is in the path of btn3 and btn2, but not btn1.
Suppose I have a background that does some navigation, but also blocks a
particular key stroke from going to the default interpretation. If I
put some fields on the card, the key is blocked for those fields. (I'm
just guessing this will work.) But suppose I make a numerical field
with up-down buttons, all grouped and I put that on the card. Maybe I
got it from a card of many such custom controls and I forgot it was a
group. The key stroke is not blocked.
Here is a real example. I hope to make soon a background for
navigation. I hope to include some effects for card navigation. My
back stack includes the inverse of the effect. Also, buttons can be
placed on the card to jump directly to some card. I want to use the
same effect stack for those. This way a series of back back back will
feel like going back. (That's the idea, anyway; it may end up looking
goofy.) This button can use the handlers of the background because it
is in the path. But, if I put the button in a group or for some reason
the group does card changes, the background is not in the path.
One solution is to send directly to the background for all cases and
just consider the background behavior of the background being after the
card in the path in some cases as a problem rather than a solution.
Another would be to put the background in the back scripts and be
careful with pass recursion.
Dar Scott
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
groups and background
I am going to translate 'Transcript Encyclopeda' into Japanese. (B (BIn a chapter of 'groups and background', I found the following (Bdescriptions. (B (B-- (BAdding and Deleting Groups: (BTip: When you create a new card, any groups on the current card are (Bautomatically placed on the new card. (B (BGroups and the Message Path: (BSince a group owns any controls that are part of the group, the group is (Bin the message path for those controls. (BGroups that are placed on a card are also placed in the message path of (Bcard controls on that card (B-- (B (BThis is explanation ONLY when a group is a 'background'. (BIs my thought right? (B (B (BUDI ([EMAIL PROTECTED] (Bhttp://member.nifty.ne.jp/UDI/ (B___ (Buse-revolution mailing list ([EMAIL PROTECTED] (Bhttp://lists.runrev.com/mailman/listinfo/use-revolution
Re: groups and background
Konichi-wa UDI-san, ... Adding and Deleting Groups: Tip: When you create a new card, any groups on the current card are automatically placed on the new card. ... This is explanation ONLY when a group is a 'background'. Is my thought right? Hai !!! :-) UDI [EMAIL PROTECTED] http://member.nifty.ne.jp/UDI/ Sayonara Klaus Major (gaijin ;-) [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re[2]: groups and background
Klaus Major wrote 02.12.19 03:29 PM$B!'(B (BKonichi-wa UDI-san, (B (B ... (B Adding and Deleting Groups: (B Tip: When you create a new card, any groups on the current card are (B automatically placed on the new card. (B ... (B This is explanation ONLY when a group is a 'background'. (B Is my thought right? (B (BHai !!! :-) (B (BThanks your quick response! (B ..and nice Japanese ;-) (B (BUDI ([EMAIL PROTECTED] (Bhttp://member.nifty.ne.jp/UDI/ (B___ (Buse-revolution mailing list ([EMAIL PROTECTED] (Bhttp://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[2]: groups and background
Konichi-wa UDI-san, ... Thanks your quick response! ..and nice Japanese ;-) Domo arigato ! (Right here ends my knowledge of nihingo ;-) UDI Regards Klaus Major [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: groups and background
On Thursday, December 19, 2002, at 06:25 AM, UDI wrote: Groups and the Message Path: Since a group owns any controls that are part of the group, the group is in the message path for those controls. Groups that are placed on a card are also placed in the message path of card controls on that card Suppose there are a couple nested groups with controls, a background with some controls and some controls not in any group on a card. The path for controls in the nested groups looks like this: ... control -- inner group -- outer group -- card -- stack ... The path for controls in the background group looks like this: ... control -- background group -- card -- stack ... But, the path for controls _not_ in any group looks like this: ... control -- card -- background group -- stack ... Note that the background group is in the path after the card for controls not in any group. (Now, I would have hoped that this would have applied to the first controls, above, too. Unfortunately, this means my field grouped with up-down buttons does not behave the same as my field. I can't think of a grouped control as a control.) Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re[2]: groups and background
Thank you for a response. (B (BI noticed about a strange message pass of a background. (B (BThe message which occurred on a card is passed to BG: (B card -- background group -- stack (B (BThis varies that a message occurred on a control: (B control -- background group -- card -- stack (B (BGenerally, not become a problem, but had better be careful. (B (B (BUDI ([EMAIL PROTECTED] (Bhttp://member.nifty.ne.jp/UDI/ (B (B (BDar Scott wrote 02.12.19 09:27 AM$B!'(B (B (BOn Thursday, December 19, 2002, at 06:25 AM, UDI wrote: (B (B Groups and the Message Path: (B Since a group owns any controls that are part of the group, the group (B isin the message path for those controls. (B Groups that are placed on a card are also placed in the message path (B of card controls on that card (B (BSuppose there are a couple nested groups with controls, a background (Bwith some controls and some controls not in any group on a card. (B (BThe path for controls in the nested groups looks like this: (B (B... control -- inner group -- outer group -- card -- stack ... (B (BThe path for controls in the background group looks like this: (B (B... control -- background group -- card -- stack ... (B (BBut, the path for controls _not_ in any group looks like this: (B (B... control -- card -- background group -- stack ... (B (BNote that the background group is in the path after the card for (Bcontrols not in any group. (B (B(Now, I would have hoped that this would have applied to the first (Bcontrols, above, too. Unfortunately, this means my field grouped with (Bup-down buttons does not behave the same as my field. I can't think of (Ba grouped control as a control.) (B (BDar Scott (B___ (Buse-revolution mailing list ([EMAIL PROTECTED] (Bhttp://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[2]: groups and background
On Thursday, December 19, 2002, at 10:54 AM, UDI wrote: The message which occurred on a card is passed to BG: card -- background group -- stack This varies that a message occurred on a control: control -- background group -- card -- stack I assume this control is in the background group. Thanks! I forgot I had put this in my path mapper. (I still haven't looked at situations with multiple backgrounds. I don't even know if there can be multiple backgrounds placed on a card.) By the way, my path mapper uses Revolution 1.1.1 on OS X 10.1.5 and uses pass to follow the path. If there is something wrong with that, then my path maps may be faulty. Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Re[4]: groups and background
On Thursday, December 19, 2002, at 12:50 PM, UDI wrote: Event on card: * bgA include bgB card -- bgA -- stack bgB ( no message ) * bg1 NOT include bg2 card -- bg2 -- bg1 -- stack ( by layer big to small ) Would this be a good summary? If the target is a control within a group then the path includes the groups it is within (inner to outer) followed by the card. If the target is not within a group (including the card) then the path includes the card followed by all background groups that are immediately owned by the card from high layer to low. Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re[6]: groups and background
Dar Scott wrote 02.12.19 01:41 PM$B!'(B (B Event on card: (B (B * bgA include bgB (B (B card -- bgA -- stack (BbgB ( no message ) (B (B * bg1 NOT include bg2 (B (B card -- bg2 -- bg1 -- stack (B ( by layer big to small ) (B (BWould this be a good summary? (B (BIf the target is a control within a group (Bthen the path includes the groups (Bit is within (inner to outer) followed by the card. (B (BIf the target is not within a group (including the card) (Bthen the path includes the card followed by all background groups (Bthat are immediately owned by the card from high layer to low. (B (BYes, I think so. (B (BAll bg is unrelated, and control on card: (B control -- card -- bg4 | (Bbg3 | (Bbg2 v (Bbg1 -- stack (B (BAll bg is unrelated, and control is included in bg3: (B bg4 ( no message ) (B control -- bg3 -- stack (B bg2 ( no message ) (B bg1 ( no message ) (B card ( no message ) (B (Bbg3 is included bg2, and control is included in bg3: (B bg1 ( no message ) (B control -- bg3 -- bg2 -- stack (B bg4 ( no message ) (B card ( no message ) (B (B (BYou can test it with such handlers: (B (B-- script for some target object ( contorol, group, card .. ) (Bon mouseUp (B theEvent (Bend mouseUp (B (B-- script for some receiver object ( group, card, stack .. ) (Bon theEvent (B put ( the short name of me ) return after field 1 (B pass theEvent (Bend theEvent (B (B (BUDI ([EMAIL PROTECTED] (Bhttp://member.nifty.ne.jp/UDI/ (B___ (Buse-revolution mailing list ([EMAIL PROTECTED] (Bhttp://lists.runrev.com/mailman/listinfo/use-revolution
Re[7]: groups and background
Sorry, I made a mistake. (B (BAll bg is unrelated, and control on card: (B control -- card -- bg4 | (Bbg3 | (Bbg2 v (Bbg1 -- stack (B (BAll bg is unrelated, and control is included in bg3: (B bg4 ( no message ) (B control -- bg3 -- card -- stack (B bg2 ( no message ) (B bg1 ( no message ) (B (Bbg3 is included bg2, and control is included in bg3: (B bg1 ( no message ) (B control -- bg3 -- bg2 -- card -- stack (B bg4 ( no message ) (B (BUDI ([EMAIL PROTECTED] (Bhttp://member.nifty.ne.jp/UDI/ (B___ (Buse-revolution mailing list ([EMAIL PROTECTED] (Bhttp://lists.runrev.com/mailman/listinfo/use-revolution
