Browser window collapses after view (adapts to viewer size)
Posted: Mon Jan 18, 2010 7:55 am
To reproduce the problem please do he following:
- Install XnView for Windows, version 1.97
- In Options->View, set 'Auto-Image-Size' to 'Fit window to image'
- In Options->View, check (activate) 'Force XnView to fit the image'
- click the menu-bar->View, and uncheck (disable) either the large tool-bar or the status-bar, or both (note: this is very important!)
- please have the browser window maximized, at least large
- in the browser window double-click an image to open the viewer (important: the image size should be quite small, at least distinctly smaller than the maximized browser)
>> As expected, the image will be displayed with a windowed viewer
- Now double-click the image again in order to switch back to the browser
>> Note, the browser window is no longer maximized or large, but has adapted to the same size that the windowed viewer previously had (bug).
I expected the browser window to restore the the previous size, before switching to the windowed view mode was done.
The always reproducible issue is quite annoying. I need to resize the browser by hand, otherwise the often extremely small window is unusable.
With either a disabled status-bar or a disabled main tool-bar it does no longer matter if other related options are activated or not (e.g. 'Use different position/size for browser and view -- or Remember last window position/size). The browser window always collapses if small images are viewed.
With my configuration I clearly can confirm at least the following (closely related) forum topics, previously issued by other users:
Maximized Browser/windowed Viewer
Option "Use different position/size for browser
browser view size wrong after exiting picture view
Another matching topic mentioned that older XnView versions (< 1.90) were free of the issue. In fact, I'm now using XnView 1.82.4 and I am able to even confirm this information.
I have good experience in software development, and I spent hours on carefully analyzing this problem while testing many configurations. Please note that there were other cases which also triggered the same problem. This even happened quite often, however, I do not post those cases since I could not 100% reliably reproduce them. I just want to underline that there certainly is something wrong, probably affecting many users.
Thanks for taking notice.
- Install XnView for Windows, version 1.97
- In Options->View, set 'Auto-Image-Size' to 'Fit window to image'
- In Options->View, check (activate) 'Force XnView to fit the image'
- click the menu-bar->View, and uncheck (disable) either the large tool-bar or the status-bar, or both (note: this is very important!)
- please have the browser window maximized, at least large
- in the browser window double-click an image to open the viewer (important: the image size should be quite small, at least distinctly smaller than the maximized browser)
>> As expected, the image will be displayed with a windowed viewer
- Now double-click the image again in order to switch back to the browser
>> Note, the browser window is no longer maximized or large, but has adapted to the same size that the windowed viewer previously had (bug).
I expected the browser window to restore the the previous size, before switching to the windowed view mode was done.
The always reproducible issue is quite annoying. I need to resize the browser by hand, otherwise the often extremely small window is unusable.
With either a disabled status-bar or a disabled main tool-bar it does no longer matter if other related options are activated or not (e.g. 'Use different position/size for browser and view -- or Remember last window position/size). The browser window always collapses if small images are viewed.
With my configuration I clearly can confirm at least the following (closely related) forum topics, previously issued by other users:
Maximized Browser/windowed Viewer
Option "Use different position/size for browser
browser view size wrong after exiting picture view
Another matching topic mentioned that older XnView versions (< 1.90) were free of the issue. In fact, I'm now using XnView 1.82.4 and I am able to even confirm this information.
I have good experience in software development, and I spent hours on carefully analyzing this problem while testing many configurations. Please note that there were other cases which also triggered the same problem. This even happened quite often, however, I do not post those cases since I could not 100% reliably reproduce them. I just want to underline that there certainly is something wrong, probably affecting many users.
Thanks for taking notice.
