I am looking into virtual custom properties (specifically: using them
to provide default values if a custom property of an object is empty
or does not exist). My understanding is that a getProp message
should percolate up the message path, and when it finds a getProp
handler it should be a
Hi Bernard,
To avoid recursion when using get or setProp, just try to lock messages:
lock messages
put the expertSettings["fileMenuContents"] of this card -- in the msg
In addition, you have to know that running code from the message box
sometimes leads to weird results:
Always prefer to crea
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
in
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 n
On 12/01/07, Jim Ault <[EMAIL PROTECTED]> wrote:
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
David Bovill wrote:
2) lock messages locks stops messages being sent and therefore any
recursion, but is badly designed in that it also blocks the initial call to
the getprop or setprop handler. This prevents a couple of very useful things
you could do when you start to try to design reuseable
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 ac
David Bovill wrote:
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
The aim is to release a re-useable component framework for Rev. A major part
of this tool framework are "views" - which are MVC style components designed
to replace or enhance the Rev Object Library.
Views can be arbitrarily nested - so if you are constructing a complex
layout you can take some "
David Bovill said:
>>
The arbitrary nesting is then
achieved by a top level view just kowing its own components and given
its
own rect where to position a subview. In this way you get a nested
series of
views each with there own "view_Rect" handler. A resizeStack event
triggers
the top-evel
Yes - if you want to take a look at the way I am going about it write to me
off list - its pretty near finished and will be open sourced with a separate
commercial license for those wanting to include the code in closed projects.
The idea is for component developers to get a revenue share on comme
>>
lock messages
put the expertSettings["fileMenuContents"] of this card -- in the msg
<<
Tres cool, Eric - that worked :-) I'm sure that you will find it
surprising, but I've never had cause to look at "lock messages"
before, and I probably would never have considered it in this context
12 matches
Mail list logo
