(Different Mark here, but...) Yes, that's by design and explicitly to allow for overriding. It's *very* useful, for example, for setting up default behavior in a behavior script and then selectively overriding that in some, but not all, the objects that use that behavior script.
The issue of script-local variables only being available in the behavior script is also by design, and is consistent with the way script-local variables work in any script. It also enforces the scope of encapsulated data in the objects in the message path. I don't see these as anomalies or inconsistencies, but as features that help implement proper object-oriented behavior. Tim- what "problems" do you see with the way this is implemented? Am I missing something? ----- -- Mark Wieder ahsoftw...@gmail.com -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Behaviors-and-the-message-path-tp4710941p4710943.html Sent from the Revolution - User mailing list archive at Nabble.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
