Virtual properties

Peter Brigham MD pmbrig at gmail.com
Tue Mar 23 17:08:52 EDT 2010


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
pmbrig at gmail.com
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
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution




More information about the use-livecode mailing list