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" <p...@lcsql.com> wrote: >On Fri, Jul 12, 2013 at 11:40 AM, Scott Rossi ><sc...@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@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode