An example of a virtual property is one that I use a fair amount:
setprop writable tf
if "field" is not in the target then exit writable
set the locktext of the target to not tf
set the traversalon of the target to tf
set the autohilite of the target to tf
end writable
getprop writable
if "field" is not in the target then return empty
put the traversalon of the target into T
put the autohilite of the target into A
put the locktext of the target into L
if T and A and not L then return true
return false
end writable
The command:
set the writable of fld "notes" to not the writable of fld "notes"
is caught by the getprop and setprop handlers and results in three
standard properties of the field being set so that the field is
editable or not editable, in this example depending on its previous
state. "Writable" is a "virtual" property because it is not actually
attached to any control, it's implemented "on the fly," as it were.
Ordinary custom properties are stored with the control they are
properties of, and endure by being saved with the stack. Most of the
time you want to use ordinary customprops for enduring attributes of
the control, storing associated data, images, etc. "Virtual"
properties have a more limited use but are quite handy for situations
where you want to be able to retrieve some sort of synthesis of
control attributes, as in a sort of "what kind of object is this" --
eg, you could have a virtual button property "userClickable" that is
true if the button is visible, enabled, not hidden by another control,
has a script containing "the storedImage of me," and has a non-empty
customprop "storedImage." And so forth.
-- Peter
Peter M. Brigham
[email protected]
http://home.comcast.net/~pmbrig
On Mar 23, 2010, at 4:26 PM, Mark Schonewille wrote:
Hi Andrew,
I think you're making it unnecessarily difficult. There are custom
properties and handlers. A custom property is saved in a stack and
contains data. A handler is a script. Such a script can set custom
properties, but not necessarily. Also, if you pass a setprop
message, a property will be set after the script is run. I never
considered a getprop or setprop handler virtual, it is just another
script. A mouseUp message that isn't passed doesn't suddenly become
virtual, does it?
--
Best regards,
Mark Schonewille
Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer
Economy-x-Talk is always looking for new software development
projects. Feel free to contact me for a quote.
Op 23 mrt 2010, om 21:00 heeft Andrew Kluthe het volgende geschreven:
I recently decided that my code would be cleaner and not so buggy
if I used
custom properties and property handlers more often instead of
global arrays
and the functions like Percent2Decimal, Validate, yaddayadda to
manipulate
them.
Given that, I just don't get the real difference between virtual
properties
and custom properties. Here is what I do get.
Virtual Properties allow you to set/handle other properties without
actually
storing a value? Correct?
Can't you do this in custom properties too? or are they considered
virtual
when you start doing that?
Anything else I should have an understanding of in regards to virtual
properties? The above is the limit of my assumptions when it comes
to the
differences between custom and virtual.
Thanks for the help,
Andrew Kluthe
_______________________________________________
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
