Multiple background group hierarchy

Ken Norris pixelbird at
Tue Mar 11 13:44:01 EST 2003

Thanks Richard,
> Date: Mon, 10 Mar 2003 21:44:43 -0800
> Subject: Re: Multiple background group hierarchy (was Goofy button
> behavior)
> From: Richard Gaskin <ambassador at>

> FWIW, I almost never use "background" scripts these days.  They're useful
> for the subset of cases in which you want a handler shared among multiple
> cards but not all cards; for all other uses I tend toward stack scripts or
> libraries ("start using").
> I think the "case" approach may give you a useful mix of some common
> functionality and some shared functionality, with the extra benefit of
> keeping your code tidily in one place. :)
> Take a look at the long ID of a grouped control:
> button id 10041 of group id 10042 of card id 10001 of stack ""
> The owner of an object is the containing object, so getting the owner of a
> grouped control is equivalent to getting the target and then delete word 1
> to 4 of it.  Very handy in many instances.
Yes, I've noticed some posted scripts that do this. Can you please give a
brief description of why/where you would use such a technique as opposed to
getting the owner of a grouped control?
>> rather like a shortcut through a bunch of nested if/then statements, as
>> opposed to operating on the group handlers. Is this correct?
> Correct.  By adding common statements before and after the case block, you
> reduce redundant code among objects.
> You could also use if-then, but case has some unique features that are worth
> becoming familiar with, such as its "fall through" in which cases not ending
> in "break" continue through the next case, allowing you to greater
> flexibility with how conditions are applied.
I really like this concept, but as I said, it's new to me. Thanks.
>>I assume
>> the string in quotes is actually a handler name which will execute only
>> within the group the target belongs to, correct?
> Yes.  
> The quotes are only truly necessary if you're working with the explicitVars
> global property set to true; otherwise they are optional, as in HC.  But as
> with HC, quoting literal strings is a good habit since it saves the
> interpreter the time needed to compare the string against its list of
> variables before deciding its not one and should instead be treated
> literally.  
> And personally, I find code easier to read when literals are quoted, but I'm
> kinda OCD that way, as I tend to put parentheses around all conditional
> expressions as well, whether required for presedence ordering or not, if
> only to help them stand out visually when skimming code.
I agree with the above. I have the same habits, which must've carried over
from my early ATARI BASIC days (now stepping out of the WayBack Machine :+))

Thanks again,
Ken N.

More information about the use-livecode mailing list