> Tim Bleiler, Ph.D. wrote >if the same handler name is present in the behavior script and the parent >script, the parent script handler is >the one that runs.
Wow! This is good to know. This could be very handy overriding a behavior handler for a specific control. As you said, there seems to be a message path conundrum here. I'm interested what Mark might have to say on this. Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net -----Original Message----- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Bleiler, Timothy Sent: Thursday, December 08, 2016 3:24 PM To: How to use LiveCode Subject: Behaviors and the message path I’m curious about what appears to me to be a confusing aspect of the implementation of behaviors. In short, behaviors have characteristics of an isolated, local extension of the message path AND characteristics of a concatenation of the parent control’s script. I’m raising the issue for two reasons: 1) to clarify how to explain behaviors to someone new to Livecode or just learning about the feature and 2) to question if all the features of behaviors are intentional or if some might be accidents of implementation and therefore may be eliminated in the future. I’ve used behaviors since they were first introduced and it’s worked well for me to think of them as an extension of the message path from the parent control. However, I recently discovered that a command in a behavior script can directly call a handler in the parent script. Furthermore, if the same handler name is present in the behavior script and the parent script, the parent script handler is the one that runs. This capability is consistent with conceptualizing the behavior script as a concatenation with the parent script and contradicts the idea that behaviors are an extension of the message path. However, script level variables in a behavior are accessible only in the object script in which they are declared, consistent with the idea of an extended message path. Finally, If a handler with the same name exists in the parent script and a behavior script, it’s possible to execute the handler in the behavior either after the parent version runs or instead of the parent version by treating the behavior script as an independent step in the message path and using control structures like “pass”, “send” and “dispatch”. There may be more of the these types of inconsistencies but that seems more than enough to provoke some discussion on this list. I realize that any problems with these features of behaviors can easily be avoided by common sense design but some discussion seems warranted for the reasons I cited above. Anybody want to weigh in on this? 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 _______________________________________________ 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
