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