Windows 10 and XnView's window

[Mixer]

Windows 10 x64, XnView 2.34

First copy of XnView came to Windows 10 partition from another hard disk together with .ini file and all other stuff of its folder.
Each time I start XnView, opens maximized browser. At the right border of its window is seen piece of Aero Lite themed window (or at least I think it is Aero Lite). Starting .exe in compatibility modes (Windows XP, Vista, etc.) doesn't cure this.
If I switch window to normal state, this piece isn't seen, but it doesn't let me drag XnView's right border to the right past the internal (left) edge of Aero Lite border (where it was in maximized window), that is I can't stretch window to make it cover whole desktop.
If I rename xnview.exe.manifest file to something else and restart XnView, then stretching window to the max becomes possible and after clicking "maximize" button it doesn't show Aero Lite border. But after that themed look of XnView controls is lost even if I rename xnview.exe.manifest back to original.
This Aero Lite glitch happens for each new copy of XnView folder.
Can't tell who to blame - Windows 10 or XnView (or manifest).

Pictures: with Aero Lite glitch and without xnview.exe.manifest

[XnTriq]

This seems to be difficult to fix

It's a known issue.

• Browser in Fullscreen does not use entire screen
• Resizing window bug
• [-1.91] Problem with maximized browser window on Vista
• 1.91.6: Not full screen window in Vista
• Strange bar displaying
• XnView and Vista - 2 little things

• Strange 'effect' in fullscreen

• Calvin Hsia's WebLog (MSDN): Windows Vista Aero BorderStyle Paint problem as non Administrator
• PSPad forum: Maximalize bug (Vista, v4.5.3 -build 2262)
• Webyog Forums: Display Bug In Sqlyog

• Autodesk Community: AutoCAD 2015: Border Glitch

[Mixer]

This is how XnView's browser looks after folder was copied again and xnview.exe.manifest was edited before freshly starting .exe from new location for the first time.

From xnview.exe.manifext was removed

Code: Select all

      <dpiAware>true</dpiAware>

Maybe culprit of this glitch was my tweaking of interface fonts, but I'm not going to change them back to check. I feel fine using dpi-unaware XnView.

[xnview]

<dpiAware> is used when you change font scaling with high dpi screen...
If you change font scaling, no problem??

[Mixer]

<dpiAware> is used when you change font scaling with high dpi screen...
If you change font scaling, no problem??

Very short answer is: no problem, because I don't use font scaling.

Well, if you're curious, just for you I performed scaling test with modified manifest which lacks <dpiAware> tags and value.

Pictures: browser right after switching on 125% scaling, viewer right after switching on 125% scaling, viewer after switching on 125% and logout/login or reboot. Viewer with maximized window is slightly affected with some garbage pixels on the right after scaling, but they disappear after user profile is reloaded. No problems with browser after reboot as well. Fullscreen isn't affected in any scaled mode.
But Viewer scales 100% sized pictures to 125% size when scaled mode is used.
And my font tweaking was lost after test, had to use Winaero Tweaker again. Don't know what would it be if I tweaked fonts at 125%.

Just a note if someone will decide to try the thing with manifest altering. I don't know what's the proper way of telling Windows to re-recognize changed manifest and would be glad if somebody explained me this. I found that if I
- rename xnview.exe to something else
- put another harmless .exe to its folder
- rename it to xnview.exe
- try to run it
- then delete it
- then rename old xnview.exe to its original - at next start XnView catches new modified manifest, so I don't have to copy whole folder and all paths in registry for assigned file types and all other stuff remain intact.

[Mixer]

How actually XnView does adjust interface to detected DPI changes?
What DPI-related code you added except for declaring application as DPI-aware in manifest?
Given the fact that 2.36 still runs on Windows 2000 you don't seem to use any functions from Shcore.dll like GetDpiForMonitor and others.
Writing DPI-Aware Desktop and Win32 Applications
Tutorial: Writing High-DPI Win32 Applications