I am trying to implement a generalized behavior that triggers after the entire execution path, rather than after the immediate script, but before the next script in the path.
Actually, having control return to a handler after "pass someHandler" would also solve my issues. A control might be clicked on, or text entered in a field, and so forth, that triggers handlers that set values and dependent values. I would like a group that owns such controls to be able to take actions *after* all such calculations. So if someone enters "foo" in field "bar", the closeField handler currently figures out what to do with that value, and anything that depends. Similarly if I click on my custom checkboxes, the mouse handler does similar calculations. I want another handler to run *after* all such things--but if I have an "after closeField" in the behavior, it simply runs after closeField, but before closeFIeld gets passed. And as near as I can tell, even without a closeField handler for the object or group, the after closeField still gets called prior to working its way up. Is there a solution other than what would be ugly hacks at the end of my closeField and mouseUp handlers? (they would be ugly because it would be properties of the group that need to be accessed, and the control could be a child, grandchild, etc. of the actual group [which is why I want the behavior to belong to the group]). The "least ugly" idea I have so far is something like concluding the universal closeField with "send aftrClsFld to the target" -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 _______________________________________________ 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
