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