Multiple background group hierarchy (was Goofy button behavior)

[Richard Gaskin]

Ken Norris wrote:

> **********
>> Date: Mon, 10 Mar 2003 13:09:03 -0800
>> Subject: Re: Goofy button behavior
>> From: Richard Gaskin <ambassador at fourthworld.com>
> 
> 
>> To avoid code redundancy, there must be a way to handle this at the stack
>> level in one handler.
> ----------
> I agree, but my lack of conceptual understanding is causing some enmity
> between scripts. Backgrounds and groups seem incongrous to me, i.e., I can
> understand backgrounds because of HC, and I can understand groups in Rev,
> but when I mix them together, stuff tends to blow up.

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").

> ----------
>> Do each of the 16 groups do completely different things in response to
>> mouseUp, or is there any common behavior among them?
> ----------
> This is semi-hypothetical. I actually have 4 background groups at this time,
> but it's certainly conceivable that I might have 16. The question is, how do
> I get various groups of buttons to do the same general things in each group
> with each group different, and still have all of them available on all
> cards, i.e., background behavior?

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. :)

> ----------
>> I'm picturing something like this, in the stack script:
>> 
>> on mouseUp
>> switch the short name of the owner of the target -- the group name
>> case "GroupName1"
>> DoSomething
>> break
>> case "GroupName2"
>> DoSomethingElse
>> break
>> end switch   
>> end mouseUp
> ----------
> You may be onto something. The switch/case concept is new to me, I'll have
> to play around with it to see how it works, but what I'm really interested
> in is the "owner of the target" thing. I haven't gotten into that much,
> except windows in HC, before now.

Take a look at the long ID of a grouped control:

  button id 10041 of group id 10042 of card id 10001 of stack "whatever.mc"

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.


> What I'm getting from your example is that the mouseUp catches the name of
> the group to which the button belongs, then executes that set of statements,
> 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.

> ---------- 
>> If you prefer to keep the scripts specific to each group inside the group
>> objects themselves, you could do something like this at the stack level:
>> 
>> on mouseUp
>> send "DoMyFunkyGrooveThang" to the owner of the target
>> end mouseUp
>> 
>> Life's too short to put that many small scripts in every button object. :)
> ----------
> The Rev way of using the "send" command is a little different, too. 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.

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 Developer of WebMerge 2.2: Publish any database on any site
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc