Woodman wrote:After updating XnView to 2.39 (on a Win 7 Laptop) it forgot all settings, i.e. programms in "open with", the size of the thumbnails, the last folder and more.
On my Win 10 Computer it works fine.
Under "Tools->Options-> System integration" "Save options" is marked as INI in folder User. When I edit the INI file manually then these settings will be load next time I start XnView but changes are not stored in this INI file.
Could you try running XnView with Admin right and check if that overcomes the problem?
cday wrote:And out of interest, could you have installed XnView while logged in to an Admin account, and now be using it from a User account?
cday wrote:I'm wondering if you might have two XnView .ini files, one in your Admin account and one in your User account??
XnTriq wrote:Woodman wrote:But, from which location is the INI file (whith old content) read?
You'll find the INI file location in Info » About....
Woodman wrote:But what happens if in the About the "INI file location" is "C:\Program Files (x86)\XnView\xnview.ini"
and in the Options>System integration "Save options as INI in folder "User""?
GeorgD (Win7 64bit: Observation + Registry Export) wrote:Hi, I reinstalled Win 7 DE 64bit Home Premium (I had the RC whose lifetime ends soon). Hence, I reinstalled XnView. Installation worked fine. .ini etc were copied to C:\Users\MYUSERNAME\AppData\Roaming\XnView which is fine. I overwrote the ini with my old ini from Win XP, after which it is important to do the setting F12 - System integration - Save Options - as ini in folder - User as without the setting, XnView might get the setting to save in XnView folder or in Windows folder which can be accessed by XnView in Win XP but can not in Win 7 - so XnView can't write there and looses the complete ini, also the one in user folder!
gothate (Folder tree very slow to load) wrote:Okay, I found where it keeps the files if you have it set to Options > System Integration > Save options > *as INI in folder - XnView. The files are kept in:
This webpage explains why (if you're curious): http://zone.ni.com/devzone/cda/tut/p/id/5538#toc3For example, take a legacy software application that attempts to write to a configuration INI file located in:
Windows Vista automatically detects that you do not have permission to save to that location. Windows Vista then copies the file (if it already exists) to:
Windows Vista then allows the write operation to succeed at the new file in the VirtualStore folder. Subsequent read and write operations for that file will always use the file copy located in the VirtualStore folder. However, the application will continue to believe that it is accessing the Program Files directory (see Figure 4).
Users browsing this forum: No registered users and 1 guest