XnView Software

______________________________________________________
Subject: 1.00: XnView window doesn't get on top of other windows when opening a new image for an existing XnView window

XnView: MP 1.00 - 64 bit
OS: Windows 11 64bit

Effect: Existing XnView window doesn't properly get on top of other windows when a new image is opened
The issue is not there for XnView Classic at the same system and it's not there for XnView MP 1.00 at another computer that has Windows 10.

To reproduce:
1. Enable "Allow only one instance of XnView" option in the settings of XnView
2. Make XnView a default program for some image format.
3. Have XnView window opened with one tab already showing an image.
4. Open a new image in the Windows Expolorer or another file management software.
Actual behaviour (bug): the opened image gets added as a tab to the XnView window and the XnView icon in the Windows taskbar starts blinking yellow

Expected behaviour: the opened image gets added as a tab to the XnView window and the XnView window gets shown on top of other windows (gets focused).
______________________________________________________

The issue is still present as of version 1.5.5.

This is not really a BUG, is just a Windows feature (thank MS).

From Windows 10 an existing background application cannot open or place a foreground window when the user has another application on the foreground, instead Window will notify this foreground attempt as a yellow blink on the taskbar. This specific behavior allows the user to keep the foreground application he choose against an abusive application like a virus trying to control the Windows foreground in an infinite loop.

If you choose "Allow only one instance of XnView" then Windows Explorer (which is on foreground) will notify the existing XnViewMP about opening a new image, but as XnViewMP is already in the background (so it is not a new launch), Windows will prevent XnViewMP to take the control of the foreground. It's up to you (as user) to approve the XnViewMP demand notified as a yellow blink. More details about this on Windows APIs/Microsoft site.

Chris

The old XnView (the Classic one) doesn't have the issue - it forces the XnView window to the foreground each time you add a new tab, which means there's a way to do it, but for some reason the MP version stopped doing it and thus if it was an unintentional change of the product behavior, that would still count as a bug by my book.
Overall, I can imagine there could be people that would prefer the current background opening way of operation, but to me it seems strange that switching between the one window operation mode and the multi-window operation mode also changes whether you get new items in background or foreground: that could instead be a separate option for those who'd have a preference for it.

The classic XnView you have is maybe a x86 version (32 bits) while XnView MP is a x64 version (64 bits) and this can produce a different behavior from Windows OS. But you can read all details about this problem/feature on "https://learn.microsoft.com/en-us/windo ... oundwindow" .

I just installed the last available x86 version of XnView MP - it has the same issue, whereas XnView Classic doesn't. Whatever complexity of making it work https://learn.microsoft.com/en-us/windo ... oundwindow describes, XnView Classic does it right, whereas XnView MP does it wrong.

how do you reproduce, XnView goes always in foreground when opening a new image

The steps I take to reproduce this are described in the original post. This happened to me at multiple Windows 11 systems where I tried that. If you don't have it the same at your system, then perhaps there's a chance there's something special about configuration or installed applications at the systems I tried it at. I recorded a video of the issue happening and attached it to this message.

can reproduce
however, it only happens if xnview window is maximized

Indeed, never realized it works ok with a non-maximized window as I always use it as maximized.

Thanks to your detailed description I can reproduce the problem.

This problem is supposed to be fixed in XnView MP 1.6.2. Please check and confirm the bug fix here.

It's fixed indeed, thanks.