Hmmm now that I am thinking about it with a full cup of coffee surging through my veins, I seem to remember Jacque mentioning in the past that a background group really belongs to the stack as a whole from a certain point of view, although as Craig says, for the purposes of the message path it has to belong to some card, and may as well be the current card.
To demonstrate the idea that a background group really belongs to the stack, create a group on a card, then delete the card. Group goes away and cannot be placed. Now create a group on a card, and set the background behavior to true. Delete the card. Notice that the new group still exists to be placed even though it doesn't exist on ANY card anymore! Groups belong to stacks, but cards are in the message path when the group is placed on them. I think this is the way to think about it. Bob On Aug 20, 2012, at 5:57 PM, Peter Haworth wrote: > I agree with that, that's why I thought the behavior I was seeing was so > weird. I started using a fresh copy of the stack and all now works as > expected so there must have been some corruption in the version of the > stack I was using. > > There might be an existing way to find out the "progenitor" - the cardNames > of a group gives a list of all the card names that group appears on and, > without exhaustive testing, it appears that the first line of that list > might be the progenitor. > > Pete > lcSQL Software <http://www.lcsql.com> > > > > On Mon, Aug 20, 2012 at 5:28 PM, <dunb...@aol.com> wrote: > >> Bob. >> >> >> It seems more natural to me that the owner is the current card. It makes >> the message hierarchy consistent. >> >> >> The "progenitor" could be a property as you suggest, but since this is not >> native, just set a custom property of the group to the id of the card that >> gave it birth. You then get everything you could ask for. >> >> >> >> Craig >> > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
