XnView Software

Pierre

Hello !

• Like I said already THERE, when I move the INI of ß-3 to a backup folder (to perform some tests),
I do not get any new fresh INI anywhere !

- I tested again at this moment:
- Nothing in the folder of the programme.
- Nothing in <Windows>
- Nothing in the <user> folder <E:\Documents and Settings\CLAUDE\Application Data\XnView\… here.
- I didn't see a key in the Registry containing a lot of entries for XnView

• Please, could you check this ? I would wish that by default XnView builds its “fresh” INI in its own folder
when the INI is missing, so it's easy to verify and to change it making tests.

TIA !

KR
Claude
Clo

V 1.90 B3

I renamed my "xnview.ini" to "!!!xnview.ini" in <user> and deleted "xnview.ini" from XnView's folder.

Restarted XnView and XnView created a new INI file for me in <user>

—> ckit

Hi Chris !

• Thanks to check.
- What does happen at your's if you state the INI in the folder of XnView (you could copy it there from <user> prior to test),
then move¦rename it and restart?

- So, you'ld be in the same situation than mine…
- I suspect there's a hitch in the case…

Ok, I tried doing this. After both INI files were deleted and XnView knew to use it's own folder. I restarted XnView and it switches back to <user> on it's own and creates the INI file there.

I'm sorry, but this is too weird and don't want any part in continuing this sorry.

Thanks for the test !

• I'll wait for the Pierre's opinion, and I'll see if someone else can reproduce this,
maybe is it OS-related with that version under XP-Pro SP1 ? This didn't occur with the 1.8x ones-

KR
Claude
Clo

I cannot reproduce. There's always a xnview.ini created in the <User> dir which is "C:\Documents and Settings\<User>\Application data\XnView\xnview.ini" (on English Windows).

In XnView 1.90 you can save the .ini file in various locations (<program folder>, <user folder>, and system folder), so I guess the search for .ini files when starting XnView has changed, too.

I guess the search order for xnview.ini is from specific to non-specific, which is:
1. <user dir> (e.g. C:\Documents and Settings\<User>\Application data\XnView\)
2. <program dir> (e.g. C:\Program Files\XnView\)
3. <system folder> (e.g. C:\Windows\)

@Pierre: Could you please provide info on this matter so that testers and users can understand what's going on?

Clo, did you try a full search to see where the file ends up? There's also the tool filemon, you could use *xnview.ini as the include filter, or just highlight xnview.ini, to see if anything by that name is getting read/written and where.

—> foxyshadis

Hello !

• I indeed made a search, I've the tool you quote, and I don't need it
because we have an excellent Search built-in Total Commander

• Finally :

- I had to remake that test 3 times more to see an INI built in <user> !
- I've even installed a button in TC to reach that deep well easily - really a stick in the b** as location - .
- However, when you make such tests, having moved you normal INI from the XnView-folder to a back-up directory - I set it there always - then you place it again there, it's no more used, since the INI in <user> takes precedence, this is like a dog which bites its own tail !
- In order to reuse your good INI containing your settings, you ought delete the INI in <user>.

• Hence, I repeat that the current default location to build a "fresh" INI is annoying, and I would much prefer it in the folder of the programme to ease the handlings.

KR
Claude
Clo

Clo wrote: Thanks for the test !

• I'll wait for the Pierre's opinion, and I'll see if someone else can reproduce this,
maybe is it OS-related with that version under XP-Pro SP1 ? This didn't occur with the 1.8x ones-

Strange, and now the xnview.ini is stored in User folder by default, so if you remove the .ini it will be created in this folder...

Yes, it works good IMO. If you rename ini to test something, you have to change option in xnview to save ini to xnview folder, close xnview, ini is created there, then you have to delete it and rename 'renamed' ini (backup) back.

Clo, could you try to do what I have suggested? I think it works good, even if not friendly to testers.