IniWriteSection bug ?

[jguinch]

Hi !

I see a strange behavior with IniWriteSection when I specify a string in the "data" parameter.

So I just want to report the problem.

I hope it will help...

For example,

IniWriteSection ($ini, "MySection", "MyKey=MyValues" & @LF & "MyKey2")

The result is :

[MySection]
MyKey=MyValues
MyKey2

I thought the function should return 0 and @ error = 1, but the line is recorded as what (without the = sign), and cannot be removed using IniDelete().

 

 

Another example :

IniWriteSection ($ini, "MySection", "MyKey1=WillBeDeletedNextTime" & @LF & "MyKey2")
IniWriteSection ($ini, "MySection", "MyKey1=MyValues2" & @LF & "MyKey2")

The result is :

[MySection]
MyKey2=MyValues2
MyKey2
MyKey2

Two lines were created...

 

 

Another example :

IniWriteSection ($ini, "MySection", "MyKey1=MyValue1" & @LF & "MyKey1=MyValue2")

The result is :

[MySection]
MyKey1=MyValue1
MyKey1=MyValue2
 

Both keys have been created with the same name.

[JohnOne]

So this 

"IniWriteSection ($ini, "MySection", "MyKey1=MyValues2" & @LF & "MyKey2")"

Creates this

[MySection]

MyKey2=MyValues2

Sorry I just don't believe you.

EDIT:

I misread, and thought you claimed it to be writing "MyKey2" when you specified "MyKey1"

Edited August 29, 2013 by JohnOne

[Melba23]

jguinch,

I can confirm your results using both 3.3.8.1 and 3.3.9.18. It looks like the function does not do a great deal of errorchecking on the input and relies on the user passing a valid string/array.

I suggest you create a Trac ticket and see what the Dev team come back with.

M23

[NewPlaza]

Yes BUT AutoIt can't check what strings you want to save to a file.

[jguinch]

Thank you for confirming.

@NewPlaza : ok, but the function should return 0 and @ error = 1, rather than do anything

[BrewManNH]

You're telling it to put a LineFeed in between your values for the key, it's valid to have that in an INI file. but AutoIt doesn't handle multiline key/values in an ini file.

[jguinch]

Yes, I know that.

In fact, the helpfile says that (for IniWrite): Multi-line values are not possible.

Well, since it is impossible, the line should not be written, and the return value should be 0 and @error = 1.

In the IniWriteSection help, we can read :

If the data is a string, then each key=value pair must be delimited by @LF

[...]

The function will set @error to 1 if the data format is invalid.

For me, the function does not sufficiently control the "data" parameter.

I still send a Trac ticket to the dev team, I'll see.

Thank you for your suggestions

[JohnOne]

Maybe @CRLF then.

I dont see any linefeeds between key and value though.

EDIT:

That @CRLF is probably nonsense I've only used the function with an array.

Edited August 29, 2013 by JohnOne

[dragan]

You could probably use this workaround:

Local $mKey = "MyValues" & @LF & "MyKey2"
MsgBox(0, 'Original value', $mKey)
$mKey = _ConverCharValues($mKey)
IniWrite(@ScriptDir & '\TempINI.ini', 'MySection', 'mKey', $mKey)
MsgBox(0, 'Saved INI value', $mKey)
$mKey = IniRead(@ScriptDir & '\TempINI.ini', 'MySection', 'mKey', '')
$mKey = _ConverCharValues($mKey, True)
MsgBox(0, 'Read INI value', $mKey)

Func _ConverCharValues($String, $Restore = False)
    If $String = '' then Return ''
    If $Restore = False Then
        Local $__Split = StringSplit($String, '')
        Local $__retVal = ''
        For $i = 1 to $__Split[0]
            $__retVal &= AscW($__Split[$i]) & ','
        Next
        $__retVal = StringTrimRight($__retVal, 1)
        Return $__retVal
    Else
        If NOT StringInStr($String, ',') Then
            Return ChrW($String)
        Else
            Local $__Split = StringSplit($String, ',')
            Local $__retVal = ''
            For $i = 1 to $__Split[0]
                $__retVal &= ChrW($__Split[$i])
            Next
            Return $__retVal
        EndIf
    EndIf
EndFunc

Edited August 29, 2013 by dragan

[guinness]

I've never understood why it has to be @LF and not @CRLF.

[BrewManNH]

IniFiles seem to be created in AutoIt with CRLF line endings.

[guinness]

Which is kind of why I think it's slightly confusing.

[Melba23]

Hi,

Looking at the WritePrivateProfileString function on MSDN I imagine that the IniWriteSection function merely splits the string (@LF was chosen for some reason) and then calls the function for each of the resulting elements that it supposes is a key=value pair. I think that it is the failure of this second split that is causing the problem - if you use "MyKey2=" there is no problem.

Incidentally, you can reassign the key (even without the =) using IniWrite - so I am even more convinced that it is a problem with the "second split" within IniWriteSection.

M23

[NewPlaza]

Thank you for confirming.

@NewPlaza : ok, but the function should return 0 and @ error = 1, rather than do anything

 

But why? AutoIt was successful in creating the keys/values you coded.

[TheSaint]

I guess one could mount an argument, that an error should be reported if @LF or @CRLF are found in an IniWrite line?

On the negative side of that though, is that you would need to test for it and make Ini writing less forgiving than it is.

I can just imagine, if you are near the beginning of a lot of Ini writing, where this could be more trouble than you want.

As Melba23 said though, for IniWriteSection, you have added an extra delimiter .... but clearly not given what is required to mark what follows it as a key or value. On top of that, the array would would have a count, which you've added to, but it doesn't know that.

Perhaps it should automatically assume 'Key', if no equal sign is detected?

The data for IniWriteSection is clearly allowed to have @LF, so what you added wouldn't be detected as an error.

Or perhaps an error for lack of equal sign?

P.S. Don't mind my crossed out musings.

[jguinch]

Thanks everybody for your answers.

The function is supposed to return an error when the format of the "data" parameter is incorrect.
Maybe it's me who did not express myself well (French), but it disturbs me.

I do not want to pollute this great forum, so I stop here.
Thank you very much for your opinion.