3.1.1 scripts not work in new version

[slahstid]

I just went from version 3.1.1 to the newest 3.2.0.1 and my scripts do not work anymore. After looking through the code and the change log, the problem was with the new boolean datatype not being backwards compatible with how it was in 3.1.1. I think there ought to be a non-compatibility list with major version changes like this that will screw up scripts. In the change log it just says "- Added: Boolean support and keywords of 'false' and 'true'.", but nothing that warns about potential issues related to the change. In fact, it is in the "Added" section and not even in the "Changed" section of the changelog.

Nevertheless, I still love autoit and appreciate the update.

[slahstid]

Here is an example code that exhibits different behavior in 3.2.0.1 than in 3.1.1

#Include <File.au3>
Global $EnableLogging = IniRead(@SCRIPTDIR & "\config.ini", "log", "Enable_Log", 0)
Global $logFilename = @ScriptDir & "\error.log"

my_FileWriteLog($logFilename, "Location 1 failed")


Func my_FileWriteLog($str1, $str2)
    If NOT $EnableLogging Then Return
    _FileWriteLog($str1, $str2)
EndFunc

If you compile and run the code with 3.1.1, you will find there is no log file. However, compile the same code with 3.2.0.1, and you find there is a log file created and written to.

Now I do realize that with such a trivial example the fix is equally trivial. The story is very different when you got long (not very well organized) code that is inherited. There is such strange behavior that I do not even know where to begin to test in the code. Let alone the fact that this is the only incompatibility I discovered so far and there may be more incompatibility issues unbeknownst to me. The thought of more unknown incompatibilities lurking around is very uncomfortable to say the least.

[SmOke_N]

Seems IniRead is passing as a string...

#Include <File.au3>
Global $EnableLogging = Int(IniRead(@SCRIPTDIR & "\config.ini", "log", "Enable_Log", 0))
Global $logFilename = @ScriptDir & "\error.log"

my_FileWriteLog($logFilename, "Location 1 failed")


Func my_FileWriteLog($str1, $str2)
    If NOT $EnableLogging Then Return
    _FileWriteLog($str1, $str2)
EndFuncoÝ÷ Ùj+À,ÁéejÆ®¶­sb4æ6ÇVFRfÇC´fÆRæS2fwC°¤vÆö&Âb33c´Væ&ÆTÆövværÒæ&VB45$DD"fײgV÷C²b3#¶6öæfræægV÷C²ÂgV÷C¶ÆörgV÷C²ÂgV÷C´Væ&ÆUôÆörgV÷C²Âb33²b33²¤vÆö&Âb33c¶ÆötfÆVæÖRÒ67&DF"fײgV÷C²b3#¶W'&÷"æÆörgV÷C° ¦×ôfÆUw&FTÆörb33c¶ÆötfÆVæÖRÂgV÷C´Æö6FöâfÆVBgV÷C²  ¤gVæ2×ôfÆUw&FTÆörb33c·7G#Âb33c·7G#"¢bäõBb33c´Væ&ÆTÆövværFVâ&WGW&à¢ôfÆUw&FTÆörb33c·7G#Âb33c·7G#"¤VæDgVæ

Edited October 24, 2006 by SmOke_N

[slahstid]

Yes, I think your first fix works. But the second fix will not work when you sucessfully read from config.ini.

However, my point is not the ease of fixing the example. It was just to show the backward incompatibility between 3.2.0.1 and 3.1.1 as requested by Larry.

[SmOke_N]

yes, I recall how strings were evaluated... It used to be that all strings evaluated as FALSE... It was changed to be something like, if a string had any character length, it evaluated as true...

I think that your code as it was written for 3.1 was flawed though. Wouldn't it always return false?

I may be wrong though, as the subject never interested me.

Lar.

I think it works as it should now. To change it would go against any other string function there is. It's not up to the IniRead to determine if something is a boolean or not. It's up to the designer to decide whether they need it to be recognized as one.

[slahstid]

I think that your code as it was written for 3.1 was flawed though. Wouldn't it always return false?

It is actually well behaved code in 3.1, albeit not very well designed as someone had pointed out. I guess it's tradeoff between supporting legacy code and making new code better. Backward compatibility is pretty important though. Look at how C++ made compromises to support C, and Java 1.5 with Java 1.4, Playstation 3 and lesser PS's, Windows XP and 98?? Ok, maybe bad example there.

Well, enough whining and back to fixing code. Thanks for replying everyone.

[jpm]

It is right that with the introduction of Boolean type all NOT/OR/AND use the following expression as a Boolean.

In 3.1.1 the string was converted to number so the result was 0 and NOT 0 result in 1

Now in 3.2.x only the string "" is false so NOT "0" result in false. It is described in the doc but I will add some precision for next beta.

That the price to pay to have a richer datatype.

So now if you want a number return from IniRead you need to converted it as suggested by Smoke_N.

For me the default value 0 in the IniRead is bad as IniRead returns always a string. It is always better to default to to same datatype.