"after after" for behaviors?

[Dr. Hawkins]

*bump*

any ideas, anyone?

On Sat, Jul 23, 2016 at 11:05 AM, Dr. Hawkins <dochawk at gmail.com> wrote:

>
> 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
>



-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462