Problem Calling Custom Card Props with the Same Name Using Switch

[Gregory Lypny]

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.