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