Virtual Custom Property Sample - Recursion Limit Problem

Richard Gaskin ambassador at fourthworld.com
Fri Jan 12 14:20:32 EST 2007


Jim Ault wrote:

> As Eric described, the getProp/setProp messages are unlike others in the
> respect that passing the message 'starts it at the card level' once again,
> thus trapping its own message and entering an inescapable recursion loop.
> 
> Lock messages=true  will mean the unwanted message will not be introduced
> into the hierarchy.  Actually, I find little or no value to the
> getProp/setProp behavior and simply program a normal handler to do the task.
> Every time I think that getProp will be an advantage, it turns out not to be
> and no pesky recursion to thwart.

And FWIW, using getProp/setProp benchmarks a tad slower than calling a 
handler, so it really depends on what you want to accomplish.

One thing getProp/setProp do well is maintain a reference to a specific 
object, the target.  So if all you need is something procedural a 
handler will do, but if you need something to act on a specific object 
which may not be the target of a user interaction then getProp/setProp 
can be helpful.

There are a few nuances of getProp/setProp which may be worth noting:

As the original post found, when using a setProp handler in the script 
of the affected object, if that setProp handler also sets a property of 
the object there will be no recursion error, since the engine does its 
own implicit sort of "lockMessages" for such instances.

But if the setProp handler is further down the message path outside of 
the target object, then no implicit locking takes place and the setProp 
handler's setting of the same property will trigger recursion.

In addition to locking the messages yourself, you can also use a 
different name for the property in which you actually store a value.  I 
tend to use a convention in which actual properties set by setProp 
handlers are preceded by an underscore to distinguish them from the 
property name accessed by other handlers:

setProp MyProperty pMyValue
    set the _MyProperty of the target to pMyValue
end MyProperty


If there's a case where I need to actual property name to be the same as 
the public property name (rare but it happens), I usually just do the 
lockMessages right in the setProp handler itself so there's less to do 
when calling it elsewhere:

setProp MyProperty pMyValue
    lock messages
    set the MyProperty of the target to pMyValue
    unlock messages
end MyProperty


-- 
  Richard Gaskin Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com



More information about the use-livecode mailing list