XMP icons displayed in thumbnails view

[JuergenK]

I'm facing a problem that I haven't seen so far: when I navigate to a folder that contains Canon RAW files (CR2) and XMP files, both file types are displayed in the thumbnails' overview:
- the CR2 files are shown as thumbnail with an image preview
- the XMP files are shown as a generic icon. This doesn't make any sense to me.

Is this a new behavior of the new version 1.93.6? It is really very inconvenient if every second thumbnail is such a generic icon. Even worse for older Canon RAW files, the THM file is also shown as a generic icon. Then 2 out of three thumbnails are these generic icons!

Is this a bug in the new version, or didn't I find the option to turn the display of these file types off. I tried to tweak the settings under Options>Browser>File List but without any success.

Another additional info that might be important: I'm running XnView under XP service pack 3(!). I upgraded this at the same time as I upgraded to XnView 1.93.6.

Thanks in advance for any help.

[xnview]

It's not a new behavior, if you want to hide some extension use option/Filelist/Custom

[JohnFredC]

Yes, this works, but keep in mind you must deliberately navigate out of the "Custom" text box (press {tab} for instance) before clicking "OK", or XnView won't remember the setting between sessions.

[Clo]

JohnFredC

Hello John !

Yes, this works, but keep in mind you must deliberately navigate out of the "Custom" text box (press {tab} for instance) before clicking "OK", or XnView won't remember the setting between sessions.

• Quite right, that proves again the lack of an [Apply] button for each config. page (like we have in TC…).

KR
Claude
Clo

[ouistiti]

Clo

I think too that an “Apply” button is very useful on the setting boxes !

Friendly,

Paul

[JuergenK]

Thanks everybody for that quick reply. Unfortunately this does not seem to work on my system.

When I run version 1.90.3 from a U3/USB stick everything works fine (i.e. the XMP icons are not visible). With version 1.93.6 the XMP files (run from my c:\ drive) are visible. The settings under options/filelist/custom are exactly identical.

I have also observed that whatever settings I enable/disable in the filelist dialog no visible changes happen.

@Pierre: I'll email you some screenshot to demonstrate the problem

[xnview]

Yes, this works, but keep in mind you must deliberately navigate out of the "Custom" text box (press {tab} for instance) before clicking "OK", or XnView won't remember the setting between sessions.

How that?? I add an extension, click ok, the setting is saved

[JohnFredC]

Here, clicking OK only saves that setting for the current session environment, NOT back to the INI. I have tested several times.

Can others confirm this behavior?

My guess is:

When directly clicked, the OK control does not grab the focus from the "Custom Files" text box. If the focus never leaves the text control, the temp value (shown to the user) will not get embedded in the data value associated with the control. That is, the control thinks the focus has never left it. So the process behind OK looks at the text control and sees the original value, not the edited one.

I've encountered this issue occasionally in my own software.

[xnview]

I can't confirm, i change the custom field, OK, quit and when i start again, i have my settings

[JuergenK]

@John: I cannot confirm this problem. This is what I have tried:

- added some new extensions in the second empty "Custom Files" textbox of the File List tab
- directly clicked OK
- shutdown of XnView and restart
- open the options dialog and check the settings => my changes had been saved

I have also tried to change the content of the first textbox. Same procedure, same result, everything is fine. Last test: change of one of the checkmarks. Again the changes are saved.

All test were done with version 1.93.6 on XP (German) / SP3.

Regards
Juergen

[JohnFredC]

I guess a good rule would be to reboot before posting about bugs in XnView.

For various reasons I hadn't rebooted my XP session for several weeks. Rebooting fixed the problem I reported above.

Sorry to post a red-herring!