On 14/01/07, Richard Gaskin <[EMAIL PROTECTED]> 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). _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
