Hi Scott, Am 23.08.2013 um 17:54 schrieb Scott Rossi <sc...@tactilemedia.com>:
> Hi Klaus: > > One reason to use a chained behavior is when you want to make some > actions, functions, or properties common to multiple object behaviors. > This new arrangement is ideal for custom controls. For example, say you > created a custom button, a custom field, and a custom scrollbar that all > share a common appearance: a "specialBorder" property that draws a blue > outline around each control. > > Now, of course each of these controls behaves quite differently from the > others -- they perform different functions, so each one uses its own > behavior script. But, in terms of appearance, they all share the > "specialBorder" property. So instead of placing a specialBorder property > setting in each object's behavior, you could place the specialBorder > setting in ONE parent behavior for ALL object behaviors. > > > The benefit of this arrangement is that if you later want to change the > specialBorder settings for all objects from blue to red, you only need to > change it one place: the parent behavior. With the old setup, the > specialBorder property would need to live in each object's behavior, and > you would need to update that property separately for each control. Kind > of a pain. > > The additional benefit of chained behaviors is the message flow is > "natural" -- mouse events automatically flow from one object to the next > without you needing to manually call some handler or retrieve code from > another object. > > In my own development, I place some custom geometry functions in parent > behaviors that are available to all my custom control behaviors, so if > (when) the time comes to update the functions, I only need to change code > in one place. And then all my custom controls will be automatically > updated at once. > > The above is quite a simple example, but hope it helps. yep, it does, thanks a lot, and John Dixon was so kind to send me your VERY enlightening stack "chained.livecode". Great example! So the answer to my initial question is definitively yes! :-) > Regards, > > Scott Rossi > On 8/23/13 5:24 AM, "Klaus major-k" <kl...@major-k.de> wrote: > >> Hi friends, >> >> I must confess that I still have no idea about the practical use of >> nested behaviors, but maybe they will fit in my current scenario? >> >> 1. I have a couple of groups and set their behavior to button A. >> 2. Now I want to switch their behaviors under certain conditons >> No big deal with some lines of script, but maybe this is possible >> without setting the new behaviors for ALL groups with nested behaviors? >> 3. I set the behvior of button A ( see above) to button B >> 4. the groups are still "connected" to button A >> 5. Now I only switch the behavior of button B and all groups >> "connected" to button A have a new behavior at once. >> Know what I mean? Is my presumption correct? Best Klaus -- Klaus Major http://www.major-k.de kl...@major-k.de _______________________________________________ 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
