IniWrite gets ignored

[Helixanon]

Hello.

Here's the code.

$pathToConfig = IniRead("settings.ini", "General", "PathToConfig", "")
If  Not FileExists($pathToConfig) Then
    TrayTip("Script", "Please point me to config file.", 5)
    $newPath = FileOpenDialog("Script", @ScriptDir, "Config files (*.cfg)", 1)
    IniWrite("settings.ini", "General", "PathToConfig", $newPath)
    $pathToConfig = $newPath
EndIf

So IniWrite with $newPath gets ignored for some reason. It returns 1, which means success, but still strange.

I tried using some random strings instead of $newPath, for example "test1235", but still no success.

But the most interesting thing is that IniWrite works when used before IniRead. That is, it gets updated both in NP++ and via the code.

Additional info:

• I have 3 more IniReads above $pathToConfig line;
• Sometimes the value just doesn't change in .ini file, and sometimes (1 case of like 10) it becomes blank (when used after IniRead).

Would appreciate any help.

Edited December 26, 2016 by Helixanon

[JohnOne]

That code, nad only that code, does not work?

[Helixanon]

Yup, .ini doesn't get updated although IniWrite returns 1. I suppose the .ini file may be busy by IniRead or something? I tried to look for any command to release the .ini file handle (like File.Close()), but there seems to be none.

[jguinch]

Try to specify the full path of the ini file :

IniWrite(@ScriptDir & "\settings.ini", "General", "PathToConfig", $newPath)

[Helixanon]

Same result. Returns 1 and .ini didn't get updated.

[Helixanon]

Oh wow wait. I actually didn't notice the "\" sign you've put. I typed it and for some reason it did, indeed, update the file.

So uhm, why was it needed to insert the scriptDir and put the backslash? Shouldn't it be working with non-absolute path?

Anyway, the issue is solved, and I thank you.

[jguinch]

It depends of the working directory.

 

 

[Helixanon]

Well the .ini file is in the same folder as the script itself.

Why did IniRead work this way? What exactly caused Write not to work?

I'm just curious, bare with me

Edited December 26, 2016 by Helixanon

[JohnOne]

There is nothing apparent which should cause that code to not work, especially if it returns 1, and is why I suspect there is more code at play since the code supplied does not test it.

But perhaps the help file is wrong and it does require full path.

[careca]

The post #1 code worked here as is.

[Melba23]

Helixanon,

I think the reason behind the problem lies in this section of the Help file (my bold):

  Quote

The working directory is set to @ScriptDir at script start and this path can be altered during the running of the script by calling FileChangeDir. But note that the current working directory can be also be changed automatically by some functions - e.g. FileOpen/SaveDialog on a successful return,

Expand  

So after a successful selection of the new path, the working directory is reset to the selected folder and so you need to specify the full path of the ini file - or reset the working folder to @ScriptDir using FileChangeDir.

M23

[jguinch]

Ah yes, thanks Melba, you refresh my memory... I remember now this behaviour with FileOpenDialog and FileSaveDialog.
I had the answer but not the explaination...

Edited December 26, 2016 by jguinch

[JohnOne]

I was under the impression that autoit3 checked running script location and environment path for file names.

must have been thinking of just dll files.

[Helixanon]

Ooooh, that's interesting. So as summary, after FileOpenDialog it tried to look for .ini file in the folder which was returned by FileOpenDialog? Funny stuff. Right, should've mentioned that the .ini file was in a same folder but I thought it was obvious

Thank you.

Edited December 27, 2016 by Helixanon

[JohnOne]

Nothing funny about it, just a little odd.