Different boolean result from Execute in AU3 versus EXE

[Zedna]

This small reproducing script shows:

Result: 1 from AU3 (Run from full Scite by F5)

Result: True from compiled EXE

$test = '1 > 0'
MsgBox(0,'Output', $test & @CRLF & 'Result: ' & Execute($test))

I think behaviour should be the same from AU3 and EXE.

Is it bug?

EDIT: My mistake, see post #3 for explanation ...

Edited January 15, 2014 by Zedna

[Melba23]

Zedna,

I get True whether I run from SciTE or the executable with 3.3.10.2 and 3.3.11.2 - what version are you using to run/compile?

M23

[Zedna]

I use these old versions:

release: 3.2.12.1

beta: 3.3.7.23

EDIT:

Sorry for my mistake!

It's not different between AU3/EXE but this way:

release: 3.2.12.1 - return 1 from both AU3/EXE

beta: 3.3.7.23 - return True from both AU3/EXE

EDIT2:

So this can be considered just as script breaking change and not bug.

Edited January 15, 2014 by Zedna

[Melba23]

Zedna,

Then the answer is simple - it is not a bug, although it might well have been back in June 2008 and December 2011 when those incredibly outdated versions were released.

M23

Edit: I have just seen your correction. It is still not a bug now - although it would have been a point to be clarified had you raised this during the 3.3.7.# Beta cycle.

[BrewManNH]

On the current release version (3.3.10.2) I get True whether compiled or run from SciTE. Considering that 3.2.12.1 is nearly 6 years old and 3.3.7.23 is a beta from over 2 years ago, does it really matter any more, also considering that 1 and True are equal in AutoIt?

[guinness]

Why are you using an outdated beta Zedna?

[Zedna]

On the current release version (3.3.10.2) I get True whether compiled or run from SciTE. Considering that 3.2.12.1 is nearly 6 years old and 3.3.7.23 is a beta from over 2 years ago, does it really matter any more, also considering that 1 and True are equal in AutoIt?

 

As I said this is only script breaking change and not bug.

It can break your old scripts compiled with new AutoIt if results are treated as string.

[BrewManNH]

Where would either of those results end up being a string?

[Zedna]

Why are you using an outdated beta Zedna?

 

I use outdated releease 3.2.12.1 because I used Windows98SE even before few years back and I have many older scripts (my and others) compatible with this version. Also many of my small helper utilities don't need any of new features (edit: and EXE is smaller :-) ). There were so much script breaking changes in later versions that I stopped upgrading of my release and I upgraded only beta version each time with new betas. New bigger projects where I could use some benefits from new features I started in latest beta. But later I started my very big project (at time of beta 3.3.7.23 on my computer) and it's so complicated/big that I didn't want to analyze/repair all later big script breaking changes in such big project so I stopped upgrading also beta versions on my computer. Even more I still use Windows XP (it's 12 years old) on my home computers and also on computers of my relatives, I'm happy with old good XP and I hate new Windows, especially Win8. I use Windows7 at work but I turned OFF UAC completely and switched to Classic mode, so it behaves/looks almost like Windows XP.

That's the whole story.

EDIT:

In the future I want to instal (or copy?) new versions (latest release+beta) to separate folders to be able to run/compile in all old/new release/beta.

I have seen some tips on the forum that #AutoIt3Wrapper_Autoit3Dir directive could be good solution for this (more paralel AutoIt versions) ...

Edited January 15, 2014 by Zedna

[Zedna]

Where would either of those results end up being a string?

$result = Execute(...)
string($result)

Edited January 15, 2014 by Zedna

[BrewManNH]

I know how to turn it into a string, but the question was how would the result of that script turn it into a string on its own? If you're expecting a boolean, don't use String() on the result because then it's not a boolean any longer.

[guinness]

If it says expressions evaluate to 0 or 1 then I guess it could be considered a script breaking change, though I don't know where it says that in the help file.

[czardas]

. . . also considering that 1 and True are equal in AutoIt?

 ;

MsgBox(0, "", String(True) = String(1))

;

I don't see them as being the same, and niether does the interpreter, unless evaluated as numeric.

On a side note, using magic numbers can sidestep a few script breaking changes if you are still using older versions of AutoIt. Perhaps this is only of passing interest to most, and I've babbled on about it too much already.

[BrewManNH]

 I'm not sure what you're saying czardas, because in the initial posts it wasn't using string. 1 and True are equal in AutoIt when compared to each other. It wasn't until the goal posts were moved to include changing them to strings was that brought out. What I wrote, when I wrote it and with the information I had at the time, was 100% correct.

[czardas]

What I mean to say is that, if the interpreter was to view the values as being equal then, string conversion should not produce a different result. So on the face of it they may both evaluate to one numerically and appear to be being treated as equal values but in reality there is a subtle difference. This interpretation also seems to make sense to me: true being boolean, and not really a number. Hmm, you know this already.

Edited January 16, 2014 by czardas

[BrewManNH]

That makes no sense at all, a string of the word True is not the same as the keyword True.

That would be like comparing these as the same.

$string = "some random text"
MsgBox(0, "", "$string" = "some random text")
 

[czardas]

That makes no sense at all, a string of the word True is not the same as the keyword True.

 

Did you think I was implying this?

[BrewManNH]

No, you didn't imply it, you stated it right out in plain text.

 

What I mean to say is that, if the interpreter was to view the values as being equal then, string conversion should not produce a different result.

How else is that supposed to be read other than saying converting a boolean keyword to a string shouldn't change it's meaning/value?

The help file is pretty clear as to what gets converted to what when dealing with booleans.

[czardas]

Well this is an interesting case.

MsgBox(0, "", True = 2)

;

This is even more interesting.

For $i = 1 To 10
    ConsoleWrite((True = $i) & @LF)
Next

;

So your statement about 1 and True being equal is somewhat misleading. There are differences. I don't see how you made the leap from what I said to your choice of rephrasing. If you pass the same value to String() you should not get different results. That's all I'm saying.

Edited January 16, 2014 by czardas

[Richard Robertson]

Non-zero integers are considered true in boolean terms. Since true appears first, the equals makes a boolean = boolean comparison.