Quantcast
Channel: LiveCode Forums
Viewing all articles
Browse latest Browse all 440

Talking LiveCode • Re: Strange custom prop behavior

$
0
0
This was maddening.

One can set a custom prop to anything one wants. But one cannot set a custom prop to a variable with the same name:

CODE:

on mouseUpput random(999) into tempset the XYZ of me to temp  --works, XYZ contains a random number.set the temp of me to temp -- NOPE!end mouseup
A new custom prop, named with the value of the variable itself, is created, and contains (what else?) the value of the variable. At least LC got that part right. :roll:

Craig
Yes if you pass a variable with content, it uses that content as custom prop name, and you then also assign it's value to itself.
Strictly speaking this probably is incorrect behaviour because the "the temp of me" (custom prop) ≠ "temp" (local var).

Not sure it will be easy to address because that's probably tied to the fabric of custom props - but you can always raise a bug report if you feel strongly about this - but can't see this will be fixed really.

I would argue represents is very dangerous coding, very error prone, confusing to others reading your code or even to yourself when you come back to this 2 years later, and should be (strongly) discouraged....

The recommendations from all sites that make recommendation on coding styles is to prefix variables with a letter than indicates their scope - and for custom props the usual recommendation is to prefix the variable name with a "c" or a "u" - ie cTemp or uTemp.

I'm sure you know this......

Statistics: Posted by stam — Thu Jul 18, 2024 2:55 pm



Viewing all articles
Browse latest Browse all 440

Trending Articles