Bug: Window position not preserved

If you are experiencing problems with "Everything", post here for assistance.
Post Reply
Franz
Posts: 5
Joined: Tue Feb 04, 2020 1:19 pm

Bug: Window position not preserved

Post by Franz » Tue Feb 04, 2020 1:30 pm

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
Attachments
everything4.jpg
everything4.jpg (679.32 KiB) Viewed 523 times
everything3.jpg
everything3.jpg (678.84 KiB) Viewed 523 times
everything2.jpg
everything2.jpg (145 KiB) Viewed 523 times

void
Site Admin
Posts: 5721
Joined: Fri Oct 16, 2009 11:31 pm

Re: Bug: Window position not preserved

Post by void » Thu Feb 06, 2020 2:36 am

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:
  • 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.

NotNull
Posts: 2335
Joined: Wed May 24, 2017 9:22 pm

Re: Bug: Window position not preserved

Post by NotNull » Thu Feb 06, 2020 4:52 pm

Franz wrote:
Tue Feb 04, 2020 1:30 pm
another one is Windows command prompt
To fix that (*):
  • Snap the CMD window
  • Right-click it''s title bar
  • Select Properties
  • Select the Layout tab
  • Click the OK button
  • Done

(*) Largely, as it didn't snap to the taskbar at the bottom ...

Franz
Posts: 5
Joined: Tue Feb 04, 2020 1:19 pm

Re: Bug: Window position not preserved

Post by Franz » Sat Feb 08, 2020 10:48 am

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...

Franz
Posts: 5
Joined: Tue Feb 04, 2020 1:19 pm

Re: Bug: Window position not preserved

Post by Franz » Sat Feb 08, 2020 11:02 am

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:
  • 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?
Thanks again,

Franz

void
Site Admin
Posts: 5721
Joined: Fri Oct 16, 2009 11:31 pm

Re: Bug: Window position not preserved

Post by void » Sun Feb 09, 2020 11:51 pm

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.
What APIs are involved in the problem/solution?
The problem is the invisible Windows 10 borders.
These invisible borders are included in the WinAPI call GetWindowRect().
These borders used to be visible (Windows 8 and earlier).
Is the issue caused by fractional scaling?
No.
Are window shadows part of the problem?
No.
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.
Scaling should not effect the issue.
Are you aware of a more global workaround in Windows that would fix all snapping issues when a >100% scaling is used?
No.

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

therube
Posts: 2711
Joined: Thu Sep 03, 2009 6:48 pm

Re: Bug: Window position not preserved

Post by therube » Mon Feb 10, 2020 5:19 am

Does WinLister or WinExplorer show these hidden borders?
https://www.nirsoft.net/utils/winlister.html
http://www.nirsoft.net/utils/winexp.html

Franz
Posts: 5
Joined: Tue Feb 04, 2020 1:19 pm

Re: Bug: Window position not preserved

Post by Franz » Mon Feb 10, 2020 8:25 am

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.
Attachments
snapped_window.jpg
snapped_window.jpg (247.21 KiB) Viewed 441 times

Franz
Posts: 5
Joined: Tue Feb 04, 2020 1:19 pm

Re: Bug: Window position not preserved

Post by Franz » Mon Feb 10, 2020 9:34 am

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!

Post Reply