I have encountered this little display artifact with all recent versions of XNView on several different computers under both Windows XP and Windows 2K and with a variety of different video cards. This clip is from Version 1.70.4
http://www.jfcinc.net/Interfaces/xnviewbug.jpg
In short: my Windows Taskbar is hidden on the left and slides into view with a mouse over. If I first minimize XNView, then select it from the task bar, when XNView restores, the artifact appears.
To reproduce it, do the following:
- Show the XNView Browser with files on the left and preview on the right.
- Maximize XNView
- Set your Taskbar properties to Autohide and Keep on Top.
- Drag your Taskbar to the left screen margin and resize it horizontally so that, when opened, it covers a portion of the XNView file pane.
- Minimize XNView.
- Use the Taskbar button to restore XNView.
- Voila!
My guess is that a repaint is not occuring on that portion of the XNView interface.
Display Bug in Browser Toolbar
Moderators: helmut, XnTriq, xnview
I am able to get various kinds of incorrect window painting when switching between different "View-Layout" settings if either "View-Folder Tree" or "View-Preview" is deselected.
It seems to me that XnView is incorrectly painting it's window under those circumstances as it somehow thinks that the folder tree or preview is visible, even though it is not.
Regards, Lostclown
It seems to me that XnView is incorrectly painting it's window under those circumstances as it somehow thinks that the folder tree or preview is visible, even though it is not.
Regards, Lostclown
John and Lostclown, thank you for your bug report and comments.
Indeed when hiding the folder tree, the area of the folder tree pane is not updated always for some reason. E.g. when hiding the area where the folder tree was before and then moving another window over XnView covering and unconvering this area, this area is not refreshed properly.
When hiding the folder tree, exiting XnView, restarting XnView, and then moving a window over XnView, the area is refreshed properly.
A while back I've reported this problem to Pierre. From what I remember Pierre wrote that this is a technical problem which he couldn't fix. Perhaps he can have a second look at this...
Indeed when hiding the folder tree, the area of the folder tree pane is not updated always for some reason. E.g. when hiding the area where the folder tree was before and then moving another window over XnView covering and unconvering this area, this area is not refreshed properly.
When hiding the folder tree, exiting XnView, restarting XnView, and then moving a window over XnView, the area is refreshed properly.
A while back I've reported this problem to Pierre. From what I remember Pierre wrote that this is a technical problem which he couldn't fix. Perhaps he can have a second look at this...

Just an update about the bug discussed in the above posts... It seems to be getting worse with each new version. Currently using 1.74.
Here is an image of a typical situation I encounter frequently.
http://www.jfcinc.net/Interfaces/xnviewproblem.jpg
I had the tree open above the thumbs and have closed the tree using the menu. The space formerly occupied by the tree pane now contains some fixed junk (on the right) and some variable junk (on the left). The variable junk captures a portion of the desktop or whatever was the previous window before returning to XNView. In the example, it shows a portion of the Snap utility I used to capture the screen image.
I haven't figured out how to deal with this except to shut down XNView, which, if I have many images open, is quite an inconvenience.
This is a serious problem for my use of beloved XNView. Please fix it!
Please?
Here is an image of a typical situation I encounter frequently.
http://www.jfcinc.net/Interfaces/xnviewproblem.jpg
I had the tree open above the thumbs and have closed the tree using the menu. The space formerly occupied by the tree pane now contains some fixed junk (on the right) and some variable junk (on the left). The variable junk captures a portion of the desktop or whatever was the previous window before returning to XNView. In the example, it shows a portion of the Snap utility I used to capture the screen image.
I haven't figured out how to deal with this except to shut down XNView, which, if I have many images open, is quite an inconvenience.
This is a serious problem for my use of beloved XNView. Please fix it!
Please?
John