Douglas,
If I read you properly, you can achieve this with a "setProp" handler, which
gets activated when a custom property on an object is attempting to be set.
For example, suppose you had two groups of controls, one called "Group1" and
the other "Group2". Both groups had a custom property called "VisState".
Assuming that Group1 is shown by default and Group2 is hidden, set the value
of the VisState property for Group1 to "true" and for Group2 to "false".
At the card/stack/backscript level (your choice), you have this code:
setProp VisState tValue
if tValue = "false" then
pass VisState -- take no action when the property is set to "false"
for the other groups
else
put the long id of the target into tTarget
lock screen
show the target
repeat with x = 1 to the number of groups
if "VisState" is in the customKeys of group x then
if (the long id of group x) = tTarget then
next repeat
end if
hide group x
set the VisState of group x to "false"
end if
end repeat
pass VisState -- very important to make sure the property gets set
(see below)
end if
end VisState
Then, all you'd need to do the switch is to have the toggle button say:
on mouseUp
if the VisState of group "Group1" is "true" then
set the VisState of group "Group2" to "true"
else
set the VisState of group "Group1" to "true"
end if
end mouseUp
Basically what happens is that when a custom property is set (in this case
"VisState"), it fires off a "setProp" message to the object whose custom
property has been changed (the target). This then travels up the message
passing hierarchy and can be trapped. If, while inside the setProp handler,
you don't specifically pass the property (in this case "VisState"), the
actual custom key does not get set. This gives you an opportunity to prevent
a custom property from being set by simply exiting out of the setProp
handler without passing the property.
Hope this is what you're looking for... if not, let me know.
Thanks!
Ken Ray
Sons of Thunder Software
Email: [EMAIL PROTECTED]
Web Site: http://www.sonsothunder.com/
----- Original Message -----
From: "Douglas Wagner" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 26, 2001 6:45 AM
Subject: Can "Registered Listeners" a la Java, be created in Rev?
> Hello:
>
> Given a window with two sets of controls, one of which is invisible at any
> one time, and a "toggle" button, which switches the visibility of the
> groups. The effect of this is a "two layer" window. Ignore, for the
moment,
> any procedural approach to this. Rather, I'm wondering is there an
objected
> oriented approach?
>
> At startup one set of controls would default to "invisible" the other
> "visible". The toggle button would originate the switch message. And this
> would be received and implemented by any "listener" which happened to be
> registered for that event. Registration would be achieved by creating a
sub
> class of a control and attaching an interface which contains a "switch"
> method. The import point here is that the window behavior can be extended
> merely by registering more listeners. There is no need to go into the code
> and modify a list of controls (or by implementing a loop which is
> procedural).
>
> The ideal solution would have "registered listeners" (like those in Java).
> Can this be done, or simulated in Revolution?
>
> DW
>
