Custom Properties

[Devin Asay]

On Apr 12, 2006, at 4:11 PM, 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.

I guess for me it boils down to keeping the underlying data and  
configuration information both separate from and directly tied to the  
interface. In other words, a custom property set to a certain value  
implies in my mind that the interface should look and behave in a way  
consistent with that value. So by setting the custom prop value and  
handling interface issues in the setProp handler I only have to worry  
about keeping the underlying data and configuration info in the state  
I want it. Is it a difference between "event-driven" and "state- 
driven" programming? (Those are my terms; I have no idea if they  
actually make sense to anyone but me.)

Devin

Devin Asay
Humanities Technology and Research Support Center
Brigham Young University