On Dec 8, 2016, at 10:31 PM, Mark Wieder <ahsoftw...@sonic.net<mailto:ahsoftw...@sonic.net>> wrote: I think the best explanation of the message path is still Richard Gaskin's chart and web page. Although I have to give props to Dar Scott for his message primer as well.
I tend to think of behavior scripts (and I know there are other viewpoints on this, so ymmv) as private backscripts fitting into the message path right behind the objects that use them. And in that sense behavior scripts have the same functionality as other library scripts: behavior handlers extend the functionality of an object or a group of similar objects behaviors can be chained: for me this makes them more useful than substacks, since you can't have substacks of substacks, but behaviors allow me to have a library with compartmentalized functionality, i.e., a math library with a special section for imaginary or complex numbers. behavior handlers can be overridden: a handler in the library script is in the message path unless a handler of the same name is earlier in the message path Thanks again, Mark. Your conceptualization matches how I thought about behaviors until recently. I may not have accurately communicated exactly what I’ve seen, so I’ll take Mike Kerner’s advice and provide a couple of examples. Just to be clear - I don’t have a problem with behaviors, I don’t think there’s anything wrong with the current implementation of behaviors, and I’m not advocating for any changes. In fact, I think it’s pretty clever. I just wanted to make sure that this is the intended design and if it is, to highlight the potential power and complexity of behaviors that can easily be missed. Example 1 Script of Button A on mouseUp TestScript end mouseUp Command ScriptInA1 Answer "you are in Button A" end ScriptInA1 Script 2 command TestScript ScriptInA1 end TestScript Given the script of button A and that script 2 is the script of the card that owns button A, then a mouseUp on Button A will result in a “can’t find handler error” when line 2 of script 2 is reached in the card. This is consistent with the traditional Livecode control based message path. Alternatively, if the behavior of Button A is set to a button with script 2, then the engine finds the script in button A and there is no error. This is consistent with the concept that script 2 is concatenated onto the end of the script of Button A. It is inconsistent with the traditional message path. Example 2 Script of Button A on mouseUp TestScript end mouseUp Command ASharedHandlerName Answer "you are in Button A" # pass ASharedHandlerName end ASharedHandlerName Script 3 command TestScript ASharedHandlerName end TestScript Command ASharedHandlerName Answer "you are in Script 3" end ASharedHandlerName Given the script of button A and that script 3 is the script of the card that owns button A, then a mouseUp on Button A will result in an answer dialog with “You are in Script 3” as the prompt. This is consistent with the traditional Livecode control based message path. Alternatively, if the behavior of Button A is set to a button with script 3 and you think that behaviors are a private message path as Mark described, you would expect that you’d still get an answer dialog with “You are in Script 3” as the prompt just like when script 3 was the card script; but you’d be wrong. Instead you get an answer dialog with the “you are in Button A” prompt, consistent with the idea that script 3 is concatenated onto the end of the script of button A rather than being the next step in the message path. Making things even more interesting - leaving script 3 as a behavior of Button A, if you uncomment the “pass” control structure in the script of button A, then a mouseUp on Button A will result in “ASharedHandlerName” being executed from Button A and then “ASharedHandlerName” executed in the behavior script in Script 3. This is a combination of the traditional message path and a concatenation of Script 3 with the script of Button A. Tim Bleiler, Ph.D. Instructional Designer, HSIT University at Buffalo _______________________________________________ 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
