I believe I may have mispoken in this thread. Setting the behavior of an object does NOT insert the behavior script in FRONT of the object in the message path. It inserts it in BACK. I know this because I have a selectionChanged handler in both the object and it's behavior, and a breakpoint in each handler. The breakpoint is triggered in the object handler, and NOT in the behavior handler, as you might expect!
The front would have been handier because then you could leave a duplicate handler in both places, and then tested each by simply setting the behavior back and forth. As is, you have to REMOVE the object's handler before you can test the behavior! Oh well. <Semi-but-not-reall-ranting> So this means this syntax makes absolutely no sense whatsoever! set the behavior of the behavior of the behavior of group "dgSites" to the long id of button "maingrids" of card "behaviors". What *actually* happens is something like: set the behavior of the long id of button "maingrids" of card "behaviors" to the behavior of group "dgSites" set the behavior of group "dgSites" to the long id of button "maingrids" of card "behaviors" but the second method won't work. So long as people doing nested behaviors are aware of this syntactical anomaly and the effect it has on the message path, all is well. <end faux-rant> Bob S _______________________________________________ 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
