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
Jim Ault wrote:
On 4/26/06 4:13 PM, "Phil Davis" <[EMAIL PROTECTED]> wrote:
Jim Ault wrote:
I am trying to grasp how the setProp and getProp handers will work and am
stuck on the following concept.
Given: that executing the following lines will 'attempt' to change the
values of custom properties and send a message to do so ...
on opencard
set the dontShowError of this stack to "true"
set the dontShowIcons of this stack to "true"
set the dontShowAnimation of this stack to "true"
end opencard
---how can another handler be triggered while this one is running?
Hi Jim,
'getProp' and 'setProp' have nothing to do per se with custom
properties. They are just syntax alternatives to 'on' or 'function'.
Your 'dontShow...' handlers would be executed much the same way any
other function or custom command issued by 'openCard' would be executed.
(Warning - TMI follows) Execution of 'openCard' is paused/suspended, and
Rev gives control to the called handler. In turn, the called handler may
call other handlers and have its own execution paused until control
comes back from the handler it called. When the original called handler
finishes running, control is returned to the original caller (openCard)
and its execution continues. (Unless of course a called handler 'short
circuits' normal control with an 'exit to top' or some such thing.)
Is that what you're asking about?
Phil Davis
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
