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