Hi,
On my system, Everything doesn't quite remember the position of its window across invocations when its window is snapped to a side of the desktop.
I'm running Windows 10 version 1909 (build 18363.628) at 3840x2160 resolution (4K). I've set Windows to use a custom scaling of 125%.
To repro:
1. Show Everything's window
2. Snap it to a side of the desktop, e.g. the right side
3. Hide or close Everything's window
4. Show Everything's window again: it's no longer snapped and has moved a little bit
This is obviously a minor issue but I'm hoping that by reporting it, I get a better understanding of why some applications such as Everything (another one is Windows command prompt) fail to preserve their snapped position, while some others have no such issue.
Franz
Bug: Window position not preserved
Bug: Window position not preserved
- Attachments
-
- everything4.jpg (679.32 KiB) Viewed 10358 times
-
- everything3.jpg (678.84 KiB) Viewed 10358 times
-
- everything2.jpg (145 KiB) Viewed 10358 times
Re: Bug: Window position not preserved
This is caused by Everything trying to bring the window into view.
The border around the window extends a few extra pixels than what is visible.
When snapping the window to an edge, the border is slightly offscreen.
When showing a new Everything window, the old window position is consider offscreen and Everything will try to bring the entire window onscreen.
I've added an ini option to disable this "bring into view" feature to the latest nightly build.
To disable the "bring into view" feature in Everything:
The border around the window extends a few extra pixels than what is visible.
When snapping the window to an edge, the border is slightly offscreen.
When showing a new Everything window, the old window position is consider offscreen and Everything will try to bring the entire window onscreen.
I've added an ini option to disable this "bring into view" feature to the latest nightly build.
To disable the "bring into view" feature in Everything:
- Download and install the latest nightly build.
- In Everything, type in the following search and press ENTER:
/bring_into_view=0 - You should see bring_into_view=0 in the status bar for a few seconds if successful.
Re: Bug: Window position not preserved
Hi,
Thanks @void for the quick fix and the nightly build, will try this in a minute!
@NotNull: The Command Prompt window actually correctly snaps and remains snapped even if minimized/restored; the problem is subtler: If the monitor --connected via DisplayPort-- physically turns off, and/or Windows turns off the display (stops sending a signal without physically turning off the monitor), then whenever the display is brought back online, snapped Command Prompt windows will be resized.
Ever since I got a 4K monitor a few years back, I've been having issues with Windows' handling of fractional scaling. I'm regularly investigating these bugs and possible solutions. Unfortunately, short of switching back Windows to 100% scaling (which simply isn't a comfortable option at 4K even on a 32" monitor), solutions must be found for each individual application...
Thanks @void for the quick fix and the nightly build, will try this in a minute!
@NotNull: The Command Prompt window actually correctly snaps and remains snapped even if minimized/restored; the problem is subtler: If the monitor --connected via DisplayPort-- physically turns off, and/or Windows turns off the display (stops sending a signal without physically turning off the monitor), then whenever the display is brought back online, snapped Command Prompt windows will be resized.
Ever since I got a 4K monitor a few years back, I've been having issues with Windows' handling of fractional scaling. I'm regularly investigating these bugs and possible solutions. Unfortunately, short of switching back Windows to 100% scaling (which simply isn't a comfortable option at 4K even on a 32" monitor), solutions must be found for each individual application...
Re: Bug: Window position not preserved
Just tested the nightly build and it works like a charm, thank you so much! Heading toward the donations page right away as Everything is the very first utility I install on any Windows machine and is an integral part of my daily work.
Would you mind elaborating a bit on the root cause of the issue and your solution (I'm a native apps developer myself)? Specifically:
Franz
Would you mind elaborating a bit on the root cause of the issue and your solution (I'm a native apps developer myself)? Specifically:
- What APIs are involved in the problem/solution?
- Is the issue caused by fractional scaling?
- Are window shadows part of the problem?
- Regarding this issue specifically, is using a custom 125% scaling different than using the 125% scaling preset? In my experience, Using a custom scaling helps fixing blurry non-high-DPI-aware apps but it doesn't seem to have any positive or negative effect on this particular issue.
- Are you aware of a more global workaround in Windows that would fix all snapping issues when a >100% scaling is used?
Franz
Re: Bug: Window position not preserved
Thanks for your support.
Although the window appears to be 100% onscreen, the invisible Windows 10 borders are offscreen. Everything is moving the window so it is 100% onscreen (including the invisible Windows 10 borders).
A visible window.
The hidden Windows 10 borders (left, bottom and right).
This is the real window size.
These invisible borders are included in the WinAPI call GetWindowRect().
These borders used to be visible (Windows 8 and earlier).
Does the snapping issue occur when using 100% scaling? -it does for me.
When snapping windows to edges, the borders should be positioned onscreen (this would show the gap as the borders are invisible).
or GetWindowRect needs to include only the visible window position (this would break too many programs).
or programs should not bring the window into view when it is offscreen (windows can be lost offscreen).
https://stackoverflow.com/questions/34139450/getwindowrect-returns-a-size-including-invisible-borders
Although the window appears to be 100% onscreen, the invisible Windows 10 borders are offscreen. Everything is moving the window so it is 100% onscreen (including the invisible Windows 10 borders).
A visible window.
The hidden Windows 10 borders (left, bottom and right).
This is the real window size.
The problem is the invisible Windows 10 borders.What APIs are involved in the problem/solution?
These invisible borders are included in the WinAPI call GetWindowRect().
These borders used to be visible (Windows 8 and earlier).
No.Is the issue caused by fractional scaling?
No.Are window shadows part of the problem?
Scaling should not effect the issue.Regarding this issue specifically, is using a custom 125% scaling different than using the 125% scaling preset? In my experience, Using a custom scaling helps fixing blurry non-high-DPI-aware apps but it doesn't seem to have any positive or negative effect on this particular issue.
No.Are you aware of a more global workaround in Windows that would fix all snapping issues when a >100% scaling is used?
Does the snapping issue occur when using 100% scaling? -it does for me.
When snapping windows to edges, the borders should be positioned onscreen (this would show the gap as the borders are invisible).
or GetWindowRect needs to include only the visible window position (this would break too many programs).
or programs should not bring the window into view when it is offscreen (windows can be lost offscreen).
https://stackoverflow.com/questions/34139450/getwindowrect-returns-a-size-including-invisible-borders
Re: Bug: Window position not preserved
Does WinLister or WinExplorer show these hidden borders?
https://www.nirsoft.net/utils/winlister.html
http://www.nirsoft.net/utils/winexp.html
https://www.nirsoft.net/utils/winlister.html
http://www.nirsoft.net/utils/winexp.html
Re: Bug: Window position not preserved
Ah, thanks for reminding me about NirSoft utilities!
What WinLister does show is that indeed a window snapped to the top-left corner has position (-8, 0). With WinExplorer you can disable the fat invisible borders by unchecking WS_THICKFRAME in the Style tab.
What WinLister does show is that indeed a window snapped to the top-left corner has position (-8, 0). With WinExplorer you can disable the fat invisible borders by unchecking WS_THICKFRAME in the Style tab.
- Attachments
-
- snapped_window.jpg (247.21 KiB) Viewed 10276 times
Re: Bug: Window position not preserved
Thanks @void for the technical details, much appreciated!
The invisible borders issue is now pretty clear.
That said I'm not entirely clear why, when "bring into view" is enabled, Everything concludes that a window is off screen when it's actually mostly "on screen". The fact that some window coordinates are negative or extend past the desktop boundaries doesn't make the window off screen.
The only bit I'm still quite puzzled about is why, after a long inactivity and/or when I turn my monitor off then on again, many of the snapped windows get resized and moved. It sounds like they do what Everything does when "bring into view" is enabled: they somehow conclude that windows are off screen and need to be moved back on screen. Only some apps are affected: Command Prompt, Chrome, Notepad++ are three examples that come to mind. Some others are not: Discord, Slack (despite both being Electron-based and thus Chrome-based).
This is getting off topic and I'm happy to move the conversation somewhere else if needed!
The invisible borders issue is now pretty clear.
That said I'm not entirely clear why, when "bring into view" is enabled, Everything concludes that a window is off screen when it's actually mostly "on screen". The fact that some window coordinates are negative or extend past the desktop boundaries doesn't make the window off screen.
The only bit I'm still quite puzzled about is why, after a long inactivity and/or when I turn my monitor off then on again, many of the snapped windows get resized and moved. It sounds like they do what Everything does when "bring into view" is enabled: they somehow conclude that windows are off screen and need to be moved back on screen. Only some apps are affected: Command Prompt, Chrome, Notepad++ are three examples that come to mind. Some others are not: Discord, Slack (despite both being Electron-based and thus Chrome-based).
This is getting off topic and I'm happy to move the conversation somewhere else if needed!