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" <[EMAIL PROTECTED]> 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
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
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
_______________________________________________
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
