Hello Jim and Jacqueline,
Jim, I've no problem with your quick answer.
The Rev tech people have resolved the issue (see below), giving a very good
answer. It turns out that the problem arises when the variable that receives
the value of the custom prop has the same name as the custom prop and not, as I
originally thought, that the same custom prop name is used for multiple
objects. Recall that I had used
put the y of this card into y,
where both the custom prop and the variable have the same name, in addition to
that name being used for custom props on other cards. I think both of you, as
well as others on the list, were able to create stacks where the problem does
not occur because you gave your custom prop a different name from the receiving
variable, such as
put the cy of this card into y,
so in those instances, my original example was not replicated, but the answer
lay hidden in yours.
Glad that it's resolved, and thanks to everyone for taking such a thoughtful
look at it!
Regards,
Gregory
Gregory Lypny
Associate Professor of Finance
John Molson School of Business
Concordia University
Montreal, Canada
> Hi Gregory, thanks for your report.
>
> The problem is a result of using the same names for the custom object
> properties and the temporary variables. If you attempt to access a custom
> property using a variable, the contents of that variable will be the key used
> to fetch the custom property, rather than the variable name
>
> Due to the way that scripts are parsed, y is not recognised as a variable
> until
> the first "put the y of this card into y". The first time, y is interpreted
> as
> the literal string "y". The second time, it is instead interpreted as the
> contents of variable y.
>
> You will find that if you enable variable checking in the script editor and
> declare your variables at the top of the mouseUp handler with the line "local
> x, y, z", the script will no longer display the values of the first card.
> This
> is because x & y are now recognised as variables from the start.
>
> For this reason, you should always use temporary variable names that are
> distinct from the names of custom properties. One suggestion which I use
> often
> is to prefix temporary variable names with t, e.g tWidth & tHeight instead of
> width & height, or alternatively prefix your custom property names with c,
> e.g.
> cX, cY, cZ instead of x, y, z.
>
>
> Ian.
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
