Question: location where ini file gets saved and loaded from

[simplenuity]

Hi Dan,

I only discovered now while performing some test that there was maybe a change I was not aware of in the way the ini file gets saved and loaded from by default?

Including TDL 7.0.13 I was able to unzip the TDL file and run ToDoList from that folder via wine. It automatically used the ToDoList.ini file in that folder. That made testing a breeze as really everything was from scratch and also didn't mess up my production installation.

I assume since the introduction of TDL 7.1 there might have been a change?

With my prod version/installation, which was continuously upgraded from older versions:

* I notice the ToDoList.ini has been last changed in February although I changed settings afterwards.

* I see in menu: Help -> About ToDoList that the following ini file is used now: C:\users\<user_name>\Application Data\Abstractspoon\ToDoList\ToDoList.ini

Now when I unzip a TDL 7.1.1.8 zip file into a new folder and run it, it grabs the ini file of my prod version instead of the ini file in the new folder.

In case this is important, please note that I start all instances with the -Z switch - picked that up from a post. I only realize now that in the manual it's a lower case "z". Not sure whether it's case sensitive as Linux in general is?

Is this change in behavior introduced with TDL 7.1 a bug or a feature?

If it's a feature, then I'd highly appreciate a hint how I can make the TDL instance use a certain ini file/ the file in it's folder.

Thanks for your time,

Ryan

[.dan.g.]

Hi Ryan

There were some changes in 7.1 in an attempt to handle Windows 10's increased security around writing to application install folders.

The current logic goes like this:

1. If there is an ini in 'AppData' AND one in 'Unzip Folder', use the newer of these (ie. the one last used)

2. If there is an ini in 'AppData' OR one in 'Unzip Folder', use that

3. If the 'Unzip Folder' is writable use put the ini there (the writability test tries to create a file in that folder)

4. Else put it in 'AppData'.

Dan

[simplenuity]

Thanks, Dan!

Moving the ini file worked, i.e. got picked up by the production installation.

While running a few tests with freshly unzipped folders (while the prod installation was running, multiple instances allowed) I once run into the situation of getting the ini created in AppData again. But couldn't reproduce the steps yet to write it down as caveat.

Thanks again,

Ryan

[.dan.g.]

>>  I once run into the situation of getting the ini created in AppData again

Thx Ryan. In that case let's leave the question 'open' just to remind me that it's not 'perfect'.

[simplenuity]

OK, sure :)
Will let you know of course if I get any wiser on this :)