Point of confusion - Custom Properties

[Phil Davis]

Jim Ault wrote:
> I am aware of the endless loop details.  They are explained in the docs.
> 
> The point is that 
> set the userFlag of this stack to "true"
> -->is supposed to trigger a message to Revolution to make the change, but
> not if this is intercepted by
> setProp userFlag val
> --examine the value and take actions
> --and the message is not passed, thus not changed.
> end userFlag
> 
> What I don't get is how the message could be sent and executed while current
> handler is still running.  If the triggers are pending messages or have to
> be handled another way, it is a mystery to me.


I believe they work the same way 'closeCard', 'preOpenCard' and 
'openCard' messages work when your script says 'go next card'. Those 
messages are fired *during* the execution of your 'go' command, and any 
like-named handlers in the path will complete before the 'go' command 
completes. The messages are an inherent part of doing the command, and 
they are fired at specific points during execution of the command; any 
handling of those messages will pause the command that fired them until 
handling is complete; then control is returned to the original command 
(e.g. 'go'), and it continues on its way.

Am I answering what you're asking, Jim?

Phil

> 
> Any working examples of how to use this part of Rev?
> 
> Jim Ault
> Las Vegas
> 
> On 4/26/06 7:43 PM, "Phil Davis" <davis.phil at comcast.net> wrote:
> 
> 
>>Hi Jim,
>>
>>Okay, I lied. I overlooked what the docs say, probably because I've
>>developed habits. I habitually use EITHER a getProp/setProp handler to
>>return/store a 'dynamic' value, OR an actual custom property, and not
>>both at once.
>>
>>If you write getprop/setprop handlers that monkey with custom props by
>>the same names, just be careful to lock messages within the handlers
>>before you touch the custom props. Otherwise, 'round and 'round she
>>goes.... at least that's how it looks to me without experimenting.
>>
>>Thanks for the enlightenment -
>>
>>Phil
> 
> 
>>>Hmmm, then I am really confused.  The docs for 2.6.1 Mac OSX say...
>>>
>>>---------------------------------------------------
>>>When you change a custom property, Revolution sends a setProp trigger to the
>>>object whose property is being changed. You can write a setProp handler to
>>>trap this trigger and respond to the attempt to change the property. Like a
>>>message, this trigger uses the message path, so you can place the setProp
>>>handler anywhere in the object's message path.
>>>
>>>Similarly, when you get the value of a custom property, Revolution sends a
>>>getProp call to the object whose property is being queried. You can write a
>>>getProp handler to reply to the request for information. Like a function
>>>call, the getProp call also traverses the message path.
>>>
>>>Using getProp and setProp handlers, you can:
>>>* validate a custom property's value before setting it
>>>* report a custom property's value in a format other than what it's stored
>>>as
>>>* ensure the integrity of a collection of properties by setting them all at
>>>once 
>>>* change an object's behavior when a custom property is changed
>>>
>>>  Note:  setProp triggers and getProp calls are not sent when a built-in
>>>property is changed or accessed. They apply only to custom properties.
>>>--------------------------------------------------------------------------
>>>The triggers are what I want to take advantage of, rather than build script
>>>lines to do the same thing.
>>>
>>>This is probably like using 'wait with messages' and 'send in 2 seconds',
>>>but it is not clear.
>>>
>>>Thanks for the quick reply, but I think there is more to the story.
>>>
>>>Jim Ault
>>>Las Vegas
>>
>>_______________________________________________
>>use-revolution mailing list
>>use-revolution at lists.runrev.com
>>Please visit this url to subscribe, unsubscribe and manage your subscription
>>preferences:
>>http://lists.runrev.com/mailman/listinfo/use-revolution
> 
> 
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>