Chained Behaviors

[Scott Rossi]

Hi Pete:

FWIW, a behavior script is not much different than using a library script,
or front/backScript.  It's a block of code that executed along the way of
the message path but stays local to the object it is assigned to.  In
fact, one could *almost* say that behaviors are in some cases more
apparent the aforementioned scripts because (for the moment) behavior
scripts can only be placed in buttons, while front/backScripts can exist
in most any control.

Another thing about behaviors is they offer a few special features, such
as their connection to groups.  When a behavior is applied to a group, you
can, for example, continually track the resizeControl message while the
group is being resized.  With other objects, the control receives the
message only after the resize event is completed.

Agreed that the display/management of behaviors in the IDE could be
improved, but the RunRev guys are working on updating the IDE, so maybe
we'll see something new there.

In the end, as Richard stated, no one is being forced to use behaviors, or
chained behaviors.  Use them or ignore them as you see fit.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 7/12/13 1:04 PM, "Peter Haworth" <pete at lcsql.com> wrote:

>On Fri, Jul 12, 2013 at 11:40 AM, Scott Rossi
><scott at tactilemedia.com>wrote:
>
>> have built a system that uses one behavior for a wide range of controls
>> using switch statements, and the higher the number of controls you have
>>to
>> support, the more complex and messier the code gets.  Chained behaviors
>> gives you another option to modularize your code.
>>
>
>Good point Scott.  Switch statements definitely get messy when they have a
>large number of case statements within them.
>
>I think this is coming down to the fact that I personally haven't come
>across a situation where chained behaviors would have been useful or there
>wasn't a perfectly acceptable alternative, at least for my programming
>style.
>
>I think one of the things that concerns me is the relative invisibility of
>behaviors, resulting in it sometimes being hard to track down where things
>happen, especially if you're looking at someone else's code.  Heck, the
>IDE
>Inspector doesn't even show a behavior field for some object types so
>tracking down the fact that a behavior is in effect is hard enough at a
>single level never mind multiple levels.  At least if you write a common
>handler and call it from each control's script, you can see right in front
>of you.
>
>Pete
>lcSQL Software <http://www.lcsql.com>
>_______________________________________________
>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
>