Problem Calling Custom Card Props with the Same Name Using Switch

Jim Bufalini jim at
Tue Dec 1 16:06:42 EST 2009

Gregory Lypny wrote:

> 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.

Yes. Even though I said I do it all the time, something I have never done is
use a single char variable or custom property name. The reason for this is I
preface all vars with either "g" (global), "s" (script local - some people
use "l"), "k" (constant), "t" (meaning "the" or "this" - handler local) or
"p" (parameter). And "c" (custom property set), or "u" (user single custom
property). So it would have to be at least 2-chars and in your case it would
have been *put the uX of... into tX. If it were a custom property set, it
would have been *put the cX["uX"] of... into tX.

As you can see, using conventions like this, automatically preclude the
issue you encountered. But since I was testing to see if there was a problem
with a 1-char custom property, I used your X, Y and Z. And I didn't use a
behavior in order not to confuse the issue.

Also, I automatically removed the spaces in the card names because as
Jacquie pointed out both First and Card are reserved words, but in general,
you make yourself vulnerable to these kinds of issues, if you use common
single words to name objects and vars.

I also prefix everything like handler and object names. This is not common,
and some are critical of the extra keystrokes, but I find, it eliminates the
possibility of my handlers or objects being named the same as another stack
in memory. And, as many know, I am a proponent of explicit vars (but I won't
get into that ;-).

Also, use of parenthesis to force resolution, while not necessary, is
another good practice and usually makes code more readable such as: 

*put "this is a line" into line (the number of lines of fld "MyField" + 1)
of fld "MyField*

You could use *put "This is a line" after...* but then you have to manage
CRs. The parenthesis above force resolution to a number first and, I think,
makes the statement more readable.

Bottom line, all of the above saves hours of debugging time for both you and
others in the long run. And, if you use verbose variable, handler and object
names, you save even more time and memory strain, six-months down the line,
when you go to make a simple change to the code.

Aloha from Hawaii,

Jim Bufalini

More information about the Use-livecode mailing list