setting a behavior with out using an ID
Richard Gaskin
ambassador at fourthworld.com
Thu Oct 23 09:16:29 EDT 2014
Good to see you here, Todd -
> I don’t like to use IDs to reference Objects. But it seems that
> the only way you can reference a Behavior is with it’s ID. Is
> that true? Is there another way?
While long IDs are normally problematic since they include the file path
to the object (which will of course change as soon as the object is
moved to another machine), behaviors are stored with a sort of truncated
long ID - from the Dictionary entry for "behavior":
The behavior property is a reference to a button containing
the script to use. The format stored in the object it's
assigned to is similar to a long ID, except that a long ID
includes the full path to the stack file and the form stored
in the behavior includes only the stack name, allowing the
reference to continue to work after the stack file has been
moved to another computer.
If your concern is simply the lack of mnemonic value in ID numbers, if
you're doing a lot of dynamic behavior assignments it's only an few
extra tokens to translate a name to a long ID:
set the behavior of grc 1 to \
(the long id of btn "cSplitter" of stack "AppResources")
In most common usage scenarios behaviors are set only once (usually
during development than at runtime), so we rarely have to script
anything like that at all, and just past a long ID reference into the
appropriate slot in the Inspector.
I know you do adventurous work though, so it wouldn't surprise me if you
had a system that needs a lot of dynamic assignments.
If neither of these address your concerns, please tell us what your goal
is and I'll bet there's an efficient way to satisfy it.
In fact, I'll bet you dinner at the next SoCal LiveCode Group meeting. :)
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the use-livecode
mailing list