"after after" for behaviors?

[Scott Rossi]

It's hard to tell from your description how you want the final script to
be triggered.  It sounds like there are multiple handlers that can
initiate the final script, and because of that I imagine you DO need to
add a trigger command to each handler.

I was going mention the possibility chained behaviors in that you can have
a sort of parent behavior that is chained to multiple child behaviors, but
this still operates the same as the standard message path: anything not
handled in the child behavior is passed along to the parent.  So to
initiate some action that that is supposed occur at the end of handler,
you need to trigger it at that point, either using a command or "pass".

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 7/29/16, 1:13 PM, "use-livecode on behalf of Dr. Hawkins"
<use-livecode-bounces at lists.runrev.com on behalf of dochawk at gmail.com>
wrote:

>*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
>_______________________________________________
>use-livecode mailing list
>use-livecode at lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode