Virtual Custom Property Sample - Recursion Limit Problem

David Bovill david at openpartnership.net
Sun Jan 14 11:31:22 EST 2007


On 14/01/07, Richard Gaskin <ambassador at fourthworld.com> wrote:
>
> That's why if I do have a need to lock messages to prevent recursion in
> getProp/setProp I tend to do so inside the getProp/setProp handler,
> rather than in the handler that calls it.
>
> But more frequently I just use an internal name for any actual property
> that needs to be set, different from the virtual property name I'm using
> for the trigger:
>
> setProp  MyProperty pMyValue
>    DoSomething
>    set the _MyProperty of the target to pMyValue
>    DoSomethingElse
> end MyProperty


Richard these are good techniques but only work for "one level down" and not
in general. If you want a group to set the property of one of its elements
(a sub-group) and allow this behavior to recurse down the chain until a
group no longer supports that property yu are pretty stuck - see quality
report http://quality.runrev.com/qacenter/show_bug.cgi?id=4220.

This is a very powerful technique which allows components to resize
themselves to an arbitrary level of nesting. The only way I have found to do
this at the moment is to pass the object calling the custom property as a
parameter like this:

setprop view_Rect [viewAbove] someRect
   put the long id of me into myView
   if viewAbove = myView then return empty

    -- resize my contents here
    -- cannot use lock messages as otherwise view_Rect is not called
    set the view_Rect [myView] of group 1 of me to innerRect
end view_Rect

This is a hack. You could use the executioncontexts but it is ugly and not
supported. It also takes up an unecessary parameter, and is not the right
behaviour. The current behaviour is the equivalent of (put the following
into any script):

on mouseUp
    lock messages
    test
end mouseUp

on test
    answer "Hello world!"
end test

and not having the test handler called as the messages are locked. The right
thing and most flexible is for the "test" handler to be called within the
objects script but not passed up the chain. For a getprop/setprop handler
this would mean that:

    lock messages
    set the view_Rect of fld 1 to someRect

would be trapped by a "view_Rect" handler in fld 1, but not by any handlers
up the chain. Votes for bug 4220 appreciated as there is no real way round
this - though unless you are interested in re-useable components it wont
affect you (yet).



More information about the use-livecode mailing list