The Owner of a background group
Bob Sneidar
bobs at twft.com
Tue Aug 21 17:39:04 EDT 2012
It might. Then again it might freak out that the group is not on any card, so rather than put him through that, I told him a way that would definitely work.
Interesting though that if you delete a card with the last instance of a background group on it, the group remains a part of the stack, but if you delete a background group from the last card, it pops a confirmation dialog, and if you confirm it removes the group from the stack.
Kinda makes sense I guess.
Bob
On Aug 21, 2012, at 2:18 PM, dunbarx at aol.com wrote:
> Hi.
>
>
> Doesn't "delete grp yourGroup" work?
>
>
>
> -----Original Message-----
> From: Peter Bogdanoff <bogdanoff at me.com>
> To: How to use LiveCode <use-livecode at lists.runrev.com>
> Sent: Tue, Aug 21, 2012 2:35 pm
> Subject: Re: The Owner of a background group
>
>
> I've seen this. Is there a way to delete a group completely from the stack? I'm
> working with a stack that has over a dozen unused groups. It is a legacy from
> when it was a HyperCard stack. The unused groups aren't causing a problem other
> than there are many with duplicate names.
>
> Can these be deleted?
>
> Peter Bogdanoff
> UCLA
>
> On Aug 21, 2012, at 8:50 AM, Bob Sneidar wrote:
>
>> 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, <dunbarx at 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 at 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 at 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 at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
More information about the use-livecode
mailing list