I was thinking that for custom controls that require a supporting library that some metadata would be allowed to come from the library. I have to think about whether this can still be done or whether it is important.
A virtual property using a getProp handler could do this, something like:
getProp metaData[myPropertyName] -- "metaData" is the custom prop set name
if myPropertyName is "libVersion"
then return the someCustomProp of stack "Library" -- goes and gets it
else pass metaData -- let the engine return the specified custom prop
end metaDataIn this case, the "libVersion" property isn't actually stored in your object; calling its value goes and queries the library stack.
It also makes it easy to enforce the "read-only" status with a setProp handler, without interfering with other custom properties or having to list all the read-only properties in a handler.
Well, before you brought the custom property set idea, for each metadata property I was thinking of (1) a setProp to ignore the set (or optionally to change the value) and optionally (2) a virtual getProp.
However, I'm not sure how to do the "read-only" for a custom property set or if it is important.
Here's an example. In this handler, "metadata" is the name of the custom property set that you want to make read-only:
setProp metaData[myPropertyName]
-- The myPropertyName parameter contains the name of
-- the property that's being set
beep
exit metaData -- don't pass the setProp
-- because the setProp trigger isn't passed, it
-- doesn't reach the engine, and so the custom
-- property you specified isn't set
end metadataThe nice thing about putting all the read-only properties in a custom property set is that you don't need a switch or if/then statement to single out the read-only properties from the writeable ones.
--
jeanne a. e. devoto ~ [EMAIL PROTECTED]
http://www.jaedworks.com
_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
