I agree Richard

On 26/05/07, Richard Gaskin <[EMAIL PROTECTED]> wrote:


But while it could be easier, I haven't seen anything yet which makes
such gadgets prohibitively difficult in Rev today.

As one example I have a table object I use in a number of apps, and a
couple other developers have used it in their work as well. (If my
client work ever slows down enough I hope to get around to packaging
that for public consumption).  I don't bother with IDs at all there,
custom or otherwise.


I'd like a look Richard - I've been doing a little more work on tables and
the new array stuff from Rev help there.

By using properties to drive the control, the getProp and setProp
handlers just refer to "the target" to find the object being acted on,
so there's no need to hard-wire IDs anywhere in the scripts


I've found that I've had to be very careful about using "the target" for
groups that nest, and can share the same name> It only works in a general
case when you use "the long id of the target"

.This property-driven method also feels more or less "natural", given
that most of the basic appearances and behaviors in Rev's own native
controls are driven by properties.


Yes it would be great to be able to write your own global properties as well
as sometimes these make for a more consitent sytax than using function
calls.

I'm sure there are cases where writing hard-wired IDs in scripts could
be useful, but I can't say I've ever needed to do so in my own work.


Me neither - just trying to explore it - it would seem that if it is
possible for a group to refer to its own controls using "btn id latID of me"
syntax - this would be better than the alternatives as it would allow the
end user to rename things?
_______________________________________________
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

Reply via email to