von dp am 09.Juli 97 um 09:09:47:
>was totally amazed that the following code actually works:
...
>addprop myArray, member 1, "I can't believe this works!"
...
>So basically, you can define any lingo object as a property NAME, not just
>a value!!! But was equally dismayed that the following DOESN'T work:
...
>put getaprop(myArray, member 1)
>--
Well, there's an explanation for this, and also maybe a much better
way of doing this anyway (see below).
-----
Explanation:
Something pretty similar to this came up on the list within the
last day or two. The thing to keep in mind is that getAProp() and
other list access keywords check for equality of reference, not
equality of value. In other words, the 'member 1' that's in your
'myArray' is equal in value to the 'member 1' in your getAProp()
statement, but in fact the two pieces of syntax are turned into
two different objects, so to speak, in two different spots of
memory. The workaround is make them refer to the same spot in
memory with a temporary variable of some sort, or to check
each element of the list for equality with '=', not with the
list access keywords. Check out this message window transcript,
I think you'll see what I'm talking about...
set myList = [:]
set mref = member 1
addprop myList, mref, "It works"
put myList
-- [(member 1 of castLib 1): "It works"]
--Solution with the same reference...
put getAProp(myList, mref)
-- "It works"
--Solution with equality check
put (getPropAt(myList, 1) = mref)
-- 1 --i.e., TRUE
put (getPropAt(myList, 1) = member 1)
-- 1
put getAt(myList, 1)
-- "It works"
-----
Better solution:
It seems you're trying to maintain distinct values for each castmember.
But there's a completely different approach, using 'script objects',
which is perhaps better suited for what you're really trying to do...
--Script of member 1
property container
--Yes, that's *all* you need.
--Message window transcript
-- Welcome to Director --
put the container of script(member 1)
--
set the container of script(member 1) to [:]
put the container of script(member 1)
-- [:]
addprop the container of script(member 1), #really, "It works"
put the container of script(member 1)
-- [#really: "It works"]
put the really of the container of script(member 1)
-- "It works"
In other words, you can attach any sort of value to the script
of a castmember. Add a dummy script with just a property variable
declaration. Voila, 'private' castemember variables which don't
pollute the global name space! (You can find out quite a bit more
about this technique by searching for threads called "Eureka!"
and "Script object" in the Direct-L archive from a couple of
years ago.)
Note that 'recompile all scripts' sets all properties back
to void values; and note that clearGlobals *doesn't* reset these
private castmember 'script object' variables. They aren't stored
with the castmember when you save the movie, of course.
However, there *is* an interesting permutation of this idea.
The existence of the property itself, since it's part
of the script text, *does* get stored in the movie. Thus,
the simple declaration of a property in a script can be
used to 'store' specific data, or maybe define different
behaviors (in the generic sense, not the D6-specific sense).
Supposing you had a bunch of castmember on screen, and some
of them were supposed to get a blue rollover, and some weren't.
If all the cast members that were supposed to go blue had as
part of their script text the code...
property useBlueRollover
...then this script could tell the difference...
on idle
--Where's the mouse?
set mc = the mouseCast
--If it's over the naked stage, not a cast member, give up.
if mc However, there *is* an interesting permutation of this idea.
>The existence of the property itself, since it's part
>of the script text, *does* get stored in the movie.
...
>on idle
> --Where's the mouse?
> set mc = the mouseCast
> --If it's over the naked stage, not a cast member, give up.
> if mc --Get the member's script object
> set smc = script(mc)
The problem is that you will get a syntax error here if the
member does not have a script attached to it. I solved this
by making sure that all members had scripts, even if only
a blank comment '--'.
I was reminded of this by the other thread this week
entitled "Re: Script Detection".
D. Plänitz