Using multiple displays and moving maximized windows from display to display by dragging the topmost 1 pixel row with the mouse has become second nature to me so when an app breaks the convention it's a thorn in my eyes.
This strange bug started occurring in the last few versions and wasn't present before them. Currently on Dopus 12.32. I think I managed to reliably reproduce it for myself by doing the following:
Computer starts with one display in PC screen only mode (2560x1600, 125% dpi)
I launch dopus
I change to extended display mode via WIN+P shortcut
On the right of the 2560 screen (aligned to top) appears a 4k display at 150% dpi and becomes the primary display instead.
I'm not sure if DPI has anything to do with all this but I thought I should mention it.
From here on trying to drag any maximized lister on the 4k display via title-bar drag at the top pixel row results in the background window being selected and dragged instead as if the dopus lister is not occupying the whole screen.
Restoring and maximizing a dopus lister doesnt help and it still behaves the same way.
Restarting dopus while in Extended mode and everything is fixed until the next switch to single mode where it starts doing it again.
Same thing happens vice-versa if the 4k screen was primary and then we switch to the 2k only one.
Forgot to mention that all other programs are unaffected by any display changes and behave as they're supposed to.
I think this is a Windows DPI scaling bug. Opus doesn't use custom window frames, so the hit-testing and maximized rect are decided by Windows itself.
You can probably see the same thing with other windows which are subject to DPI scaling.
With Opus that means when it's on a monitor that uses something other than the system DPI, since Opus doesn't currently do per-monitor scaling. (Or the system DPI was changed and Opus hasn't been exited and re-launched yet.)
A good thing to try it with is DebugView - Sysinternals | Microsoft Learn which doesn't support high DPI at all, so it'll always be scaled by the OS. If you maximize DebugView and then click the top-right corner of the screen to try and close it, you will actually close the window UNDER it (if any) because Windows sends the click to the wrong place.
This has been a bug in Windows for as long as high DPI support has been in Windows. Quite a bad one.
Thanks for explaining Leo. You might be just right as before I was probably using both screens at 125% and it didn't occur to me then. It probably started after I switched the 4k to 150% but I kind of thought the dpi bug would always happen but it dint when screens were using the same non-standard one.
I'd love them to fix it as I've closed the wrong window many times because of that bug!
All my screens are the same DPI (200% scaling) so it only affects things with no DPI support at all (like the DebugView example), but that's still enough software, including a lot of Microsoft's own tools, that I run into it quite often.
Multi-monitor mixed DPI is a whole extra can of OS bugs on top of that, unfortunately.
(Windows 10 can't draw the window frames properly in high DPI either, so it seems someone on the Windows team has trouble with basic linear scaling math.)
Agreed. The whole DPI scaling is like a half-assed, slapped on semi-feature which fixes a major problem with band-aids.
I see the same happening to clear-type and some new OLED display types (read LG and Samsung) where it just looks bad and they don't use the community proposed solutions to fix them for a long time, but that's another story.
Thanks again and all the best.
