Behaviors and the message path

[Bleiler, Timothy]

On Dec 8, 2016, at 10:31 PM, Mark Wieder <ahsoftware at sonic.net<mailto:ahsoftware at 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