Custom Properties

[Mark Smith]

I don't tend to use getProp/setProp all that much, I must say, and as  
you know with Rev, there are usually many ways of achieving a given  
aim. One way I use setprop is when I'm storing some data into a  
custom prop of some object, and I need things to happen whenever that  
custom prop is changed, though, as you point out, a setCPtoValue  
command would work just as well. It just feels more natural to me to  
set a custom prop at those times...but that's just how I think.

The setProp message also gets sent up the message path until handled,  
so if you have a bunch of fields on a card, each containing a list of  
numbers that you want to total, at different times for each field,  
you could have in the card script

setProp tTotal
   put the text of the target into numList
   replace cr with comma in numList
   put cr & sum(numList) after the target
end tTotal

So you can then - set the tTotal of fld 1 to empty
and field 1 is then updated to show it's total.


Of course you could achieve this any number of ways, but it's another  
option, which might be more or less convenient depending on context  
and your own view.


Best,

Mark

On 12 Apr 2006, at 23:11, J. Landman Gay wrote:

> Devin Asay wrote:
>> On Apr 12, 2006, at 11:44 AM, Thomas McGrath III wrote:
>>> Does anyone have any examples on the get/setProps in real usage?  
>>> I  have been using custom props but not the setProp etc. I would  
>>> love  some more insightful ideas on it's usage.
>> The way I use it is much more pedestrian than the Marks'. For me  
>> it's  a really easy way to make sure my interface objects get set  
>> to the  proper states. For example, let's say I want to toggle  
>> between an  'editable' and 'noneditable' mode for a text editor:
>> setProp editMode pMode
>>   if pMode then
>>     enable button "Save"
>>     enable button "TextColor"
>>     set the lockText of fld "myfld" to true
>>     set the traversalOn of fld "myFld" to true
>>   else
>>     disable button "Save"
>>     disable button "TextColor"
>>     set the lockText of fld "myfld" to false
>>     set the traversalOn of fld "myFld" to false
>>   end if
>>   pass editMode -- the docs say you have to explicitly pass it to   
>> have it set the prop
>> end editMode
>
> I have thought about doing this many times, but I usually revert  
> back to using a command or function handler instead, probably out  
> of habit. For example, the above could also be done by:
>
>   setEditMode true
>
> rather than using a property assignment like "set the editmode...".  
> For me, seeing a handler name informs me that there is a related  
> script somewhere. Setting a property doesn't give me the same,  
> immediate knowledge; later on when I've forgotten why I wrote a  
> script a certain way, seeing a statement that sets a property  
> doesn't tell me as clearly that a lot of other actions will be  
> taking place at the same time.
>
> Now I'm curious what's the advantage, if any, of using a setProp  
> handler over a standard command handler? This isn't just to you,  
> Devin, but to anyone who uses these regularly.
>
> I should also say that I do use one of these routinely: when I set  
> a stack's version number property, I often use a setProp handler  
> that updates the version display in an About box, or wherever else  
> it happens to show. In this case, I usually set the version  
> property from the message box, so a setProp handler gives me an  
> automated way to get a lot of stuff done without having to type in  
> (and remember) a handler name. But when called from inside a  
> script, I'm not sure what the advantages would be.
>
> -- 
> Jacqueline Landman Gay         |     jacque at hyperactivesw.com
> HyperActive Software           |     http://www.hyperactivesw.com
> _______________________________________________
> 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