using a variable for the name of a custom property - safe?

[Jim Ault]

<Full question text below>
Short answer is yes.
> Does anyone do this routinely? (Refer to a custom property with a
> variable name) Is this unsafe? Or something that might change in 2.9
> or 3?
> (The reason I'm doing this is that I have a lot of custom properties
> that contain binary file data with sequential names and want to spit
> them all out into files in a simple loop and not manually by naming
> each explicitly- perhaps there is a simpler way?)
Yes, I do this, and this is not a trick that will disappear.  I will show an
unambiguous notation further down that should help you.

> on mouseUp
>      set the uFavColor of me to "blue"
>      set the tProperty of me to "red"
>      put "uFavColor" into tProperty
> 
>      answer the tProperty of me
> end mouseUp
My answer is "blue", which is the correct answer.
It is indeed (the uFavColor of me)
and (the tProperty of me) is "red"

and later tProperty is interpreted to be "uFavColor"

----These are not the same thing:
answer tProperty   => uFavColor
answer the tProperty of me  => blue
 put (the tProperty of me) into propName  => red
 answer the propName of me    => empty

which means (the red of me) is empty.
> 
> Obviously the caveat of using the same name for a variable and custom
> property is well advised! Since the Rev parser obviously first checks
> for the value of the variable before the custom property.
Actually the caveat is true, and a couple others can also cause problems.
=> assuming the *current custom property set*  !!
=> if uPropName01 does not exist, then it is created

In this case, the property is silently created or changed and is not easily
visible.  I would recommend that you use notation that specifies both the
property and the property set to avoid crossing data storage.

set the myImageStorSetA["uFirstImage"] of me to url ("binary:podium01.jpg")
set the myImageStorSetA["uSecondImage"] of me to url ("
binary:podium02.jpg")
set the imageStorSetB["uFirstImage"] of me to url ("binary:podium01.jpg")

put "44" into indx
get ("uSecondImage" & indx & "small")
set the myImageStorSetB[it] of me to url ("binary:speaker213.jpg")

First Rev either creates the new custom property set "myImageStorSetA"  or
uses the existing one.
Second Rev either creates the new custom property "uFirstImage"  or uses the
existing one.

Further:  looping is easily done by
put "44" into indx
get ("uThirdImage" & indx & "small")
set the imgStorSetA[it] of stack "sidekick" to url ("binary:pod.jpg")

Ambiguity is not your friend with custom properties.

Hope this helps

Jim Ault
Las Vegas



On 11/8/07 3:17 PM, "Josh Mellicker" <josh at dvcreators.net> wrote:

> I have a number of custom properties to deal with, and would rather
> do this in a loop.
> 
> So, on a lark, I tried this:
> 
> on mouseUp
>      set the uFavColor of me to "blue"
>      set the tProperty of me to "red"
>      put "uFavColor" into tProperty
> 
>      answer the tProperty of me
> end mouseUp
> 
> 
> Obviously the caveat of using the same name for a variable and custom
> property is well advised! Since the Rev parser obviously first checks
> for the value of the variable before the custom property.
> 
> My question, though, to save me a lot of lines of code, is:
> 
> Does anyone do this routinely? (Refer to a custom property with a
> variable name) Is this unsafe? Or something that might change in 2.9
> or 3?
> 
> I don't want to depend on a technique that is more trickery than
> solid programming.
> 
> 
> (The reason I'm doing this is that I have a lot of custom properties
> that contain binary file data with sequential names and want to spit
> them all out into files in a simple loop and not manually by naming
> each explicitly- perhaps there is a simpler way?)