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" <[EMAIL PROTECTED]> 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
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
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
