LiveCode Forums.

I am on a Mackbook air ( iOS 10.10.3.) running Livecode 7.0.5.
I set the property explicitVariables to false, which I also confirmed through the message box, however, when I try to put a field into a variable, I got the following message

"button "strip letters": compilation error at line 2 (Chunk: can't create a variable with that name (explicitVariables?)) near "x", char 43"

.
Here is the very simple code I am using that generated the error message described above I had the same problem before, running livened 7.0.1. Thanks

Hi Carlo,
Welcome to the forum.

This sounds like you have Strict Compilation Mode enabled which will force you to define x before you use it
local x
on mouseUp
...


Simon

In that handler the variable "nolines" has not been assigned a value.

FourthWorld wrote:In that handler the variable "nolines" has not been assigned a value.

That is true, however it is irrelevant to my problem; I changed the name of the variable to x from nolines in order to verify that was nothing going on at the level of the name chose for the variable. I hope this clarifies things, Thanks for your reply!

Simon wrote:Hi Carlo,
Welcome to the forum.

This sounds like you have Strict Compilation Mode enabled which will force you to define x before you use it
local x
on mouseUp
...


Simon

Hello Simon,
thank you so much! That was exactly where the problem lied. So, if I understood correctly, the strict compilation mode "overpowers" the set to false of the explicitVariables property. Thanks again! Carlo

I'd think using an integer as the counting variable would also be illegal. It should be something like:

Jacque.

And the rest of the planet.

I would have bet money that the construction: was indeed illegal. It is not: Now you only get a bunch of "5's", so the construction is not particularly useful, but no error is thrown. And I am not sure what the parser is doing there, multiplying 5 by the, er index variable "1", or the number "1". (Smoke rising from top of head)

I did play around with a few variations, and found that something like this: threw what I would expect it to at compile time, a bad chunk destination.

I found another way to get an error with the same sort of nonsense, not at compile time, but rather at runTime, and the error was "...bad destination (numeric?)". But I cannot remember what I did to get it.

Anyway, stay away from that sort of thing.

Craig Newman

Interesting. The compiler may be interpreting it as (1=1) so it becomes "repeat with true to 3". And then when it tries to deal with that it produces garbage. Or something.

Typo? 1=1 I think is supposed to be i=1 as in the original post Carlo goes on to say
put the second item of line i ...
That doesn't explain issues with the engine interpreting 1=1 this way though. I think you have it, described in the post above this one jaque

Yes and no, that is to say, no.

Both: will not compile. I am frightened to death to try: Craig

Oh, right, I'm sure it's a typo now that you mention it. But the tangent has been interesting.

Craig, what's the worst that could happen? So what if you have to restore your hard drive from backups?

So what if there is no backup to use because the implosion created a black hole and swallowed it. That's right, so what? It would swallow you and me and the world too. And the rest of the solar system. Proxima Centauri is looking a bit nervous as well.