Problem Calling Custom Card Props with the Same Name Using Switch

[Gregory Lypny]

Hello Jacques, Jacqueline, Craig, and Jim,

Sadly, it is a bug then.  The consequences, as I said, are potentially serious for any stack that uses custom props with the same name to monitor various states of objects.  Jacqueline and Jacques (kind of musical, eh?), I experimented a little more and find that it is not limited to using y as the variable name or one-letter variable names in general.  I get the same problem when x is used for the custom prop on two different cards and when a two-letter name, xV, is used.  The problem is also there if you use an If control structure rather than Switch, and it is not limited to cards.  I set props for two buttons in the same way and lost the value of the same-named prop for the second button.  I haven't used Behaviours yet, but you can readily see how the problem could be pervasive there.

Jim, I appreciate the fix you suggest, but when you say long name, do you mean the long name of the card?  If so, then that does not work either.  In any case, a bug report is in order.

	Regards,


	Gregory Lypny
    
	Associate Professor of Finance
	John Molson School of Business
	Concordia University
	Montreal, Canada





On Mon, Nov 30, 2009, at 4:42 AM, Jacques Hausser wrote:

> Related remark: I remember I had sometime (not systematically) problems when giving one letter names to variables or parameters (e.g. a,b or x,y, which are so standart, in regression for example), but I was too lazy to digg deep in this question, it was simpler to change the name of the variable... but it IS some hidden pitfall somewhere.
> 
> Jacques


On Mon, Nov 30, 2009, at 4:42 AM, Jacqueline Landman Gay wrote:

> This fails for me too, but only if I keep the property name you 
> assigned. If I change the property to "cY" it works as expected. I'm not 
> sure why, but I'd guess the engine is using "y" for something. Since I 
> always preface my custom properties with "c", I haven't run into this 
> before, but I think you should probably bug-report it. It's an odd one.


On Mon, Nov 30, 2009, at 4:42 AM, Craig Newman wrote:

> Confirmed. And it's odd, because the property value is there, at least 
> right at the beginning:







On Mon, Nov 30, 2009, at 4:42 AM, Jim Bufalini wrote:

> Use the long name.
> 
> Aloha from Hawaii
> 
> Jim Bufalini


On Mon, Nov 30, 2009, at 4:42 AM, I originally wrote:

> 	Hello everyone,
> 
> 	Can we assign the same name to custom props of two different objects, for example, the modificationDate of Card 1 and the modificationDate of Card 2?
> 
> 	I created a simple stack with two cards named First Card and Second Card, a common button that assigns custom props to each and another common button to show the values of each card's custom prop.  The handler in the button that sets the custom props uses Switch and it looks like this.
> 
> on mouseUp
>   switch the short name of this card
>      case "First Card"
>         set the x of this card to 123
>         set the y of this card to 456
>         break
>      case "Second Card"
>         Set the y of this card to "ABC"
>         set the z of this card to "DEF"
>         break
>   end switch
> end mouseUp
> 
> What is important here is that both cards have a custom prop with the same name, y, and that y has a different value for each (123 or ABC).  The button to show the values of the props also uses Switch.
> 
> on mouseUp
>   put the short name of this card
>   switch the short name of this card
>      case "First Card"
>         put the x of this card into x
>         put the y of this card into y
>         put return & "x" && x && "y" && y after msg
>         break
>      case "Second Card"
>         put the y of this card into y
>         put the z of this card into z
>         put return & "y" && y && "z" && z after msg
>         break
>   end switch
> end mouseUp
> 
> If you click this button while on the first card, it correctly puts into the message box
> 
> 	First Card
> 	x 123 y 456
> 
> But if you click it while on the second card, you get
> 
> 	Second Card
> 	y  z DEF
> 
> where y is empty.  But, comment out the statement involving y in the first case of Switch and the second case will work correctly!
> 
> 	case "First Card"
>         put the x of this card into x
>         -- put the y of this card into y
>         put return & "x" && x && "y" && y
>         break
> 
> In other words, a statement that retrieves a custom prop in the case of Switch that should be by-passed is somehow affecting the retrieval and use of a custom prop with the same name in the case of Switch that is executed.  I hope someone can tell me that I've made a mistake because, otherwise, this could have serious consequences for stacks whose objects have custom props that monitor the state of an object and these props have the same names, e.g., the modificationDate of Card 1, the modificationDate of Card 2, etc.
> 
> Regards,
> 
> 	Gregory