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

[Josh Mellicker]

Thanks Sarah and Jim!

On Nov 8, 2007, at 4:12 PM, Jim Ault wrote:

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