search

hoppfrosch / WindowPadX

Enhancements on original WindowPad (by Lexikos)
http://hoppfrosch.github.com/WindowPadX
225 stars 41 forks source link

Windows 10 border fix #21

Closed pacobyte closed 6 years ago

pacobyte commented 6 years ago

This fix addresses issue #14. It relies on my updated version of the WinGetPosEx function. This function accounts for the newer way that Windows 10 defines its window border sizes, and therefore, addresses the "gap" mentioned in the bug report.

If you agree to this change, how should the inclusion of the WinGetPosEx function be handled? Shall I commit it as a new file to the _inc folder?

Also, I just realized that the changelog will need to be updated in WPXA.ahk.

johannes-z commented 6 years ago

Hey I tested your PR. Skype (normal desktop App) is still kinda buggy. Can you confirm?

pacobyte commented 6 years ago

The version of Skype on my PC (the one that came with Windows 10, I believe) seems to be working fine. How is it buggy for you?

Skype version: 12.8.487.0

johannes-z commented 6 years ago

That's the Windows 10 Store App then. I'm using the native desktop app. Anyway, this is what it looks like after moving it. I think this is due to the window rendering the border itself somehow to accomplish the same look in e.g. Windows 7.

Skype

pacobyte commented 6 years ago

@johannes-z Are you using my latest version of the WinGetPosEx function? If not, you can get it here. I haven't added it to the PR because I am waiting to hear from @hoppfrosch about it.

johannes-z commented 6 years ago

@RiseUp26 Yes, I do. Just updated again just in case. If I align the window right this happens. If I move it to the top right and then to right it's positioned correctly...

DoCode commented 6 years ago

@RiseUp26, thanks for your PR! It works very nice. But I think it's a common Windows problem. When windows are closed and reopened, Windows doesn't restore the size correctly. The size and position are the old one, without your optimizations with WinGetPosEx

hoppfrosch commented 6 years ago

I don't use Win10 - and don't use WindowPadX anymore ... so I really don't have a preference.

So if you consider your pull request as "ready" I will pull it .

pacobyte commented 6 years ago

@hoppfrosch It doesn't seem ready quite yet, but I will let you know.

@DoCode Thanks for the specifics. It sounds like there's something I missed in the restoration code, so I'll look into that.

@johannes-z That's interesting. Are you using the default version of WindowPadX.ini, or did you customize your hotkeys and commands in that file?

DoCode commented 6 years ago

@RiseUp26, hm. I think it's a Windows issue! Try to place the Windows File Explorer to the left side. Close it and reopen.

pacobyte commented 6 years ago

@DoCode It appears you may be right! I'm guessing Windows thinks that the window is slightly off-screen, so when it reopens the window, it does us a "favor" and repositions it so it is wholly on-screen. This is easily fixed by simply moving it again with your hotkey, of course.

johannes-z commented 6 years ago

I think it's the same problem that happens with skype. It's just how those "borderless" windows are rendered. The gap that's created is exactly the border where you can resize the window...

pacobyte commented 6 years ago

@johannes-z Yes, and the whole point of this PR is to account for that "invisible" border so that windows can be positioned without the gap.

DoCode commented 6 years ago

@DoCode It appears you may be right! I'm guessing Windows thinks that the window is slightly off-screen, so when it reopens the window, it does us a "favor" and repositions it so it is wholly on-screen. This is easily fixed by simply moving it again with your hotkey, of course.

@RiseUp26, yes that the point. And that's annoying... A tool that restores the last position correctly would be nice! :-)

pacobyte commented 6 years ago

@hoppfrosch I've added the WinGetPosEx.ahk file, so it should be ready to go now if you want to pull it.

mmikeww commented 5 years ago

@DoCode It appears you may be right! I'm guessing Windows thinks that the window is slightly off-screen, so when it reopens the window, it does us a "favor" and repositions it so it is wholly on-screen.

Just for clarity:

When you guys are accounting for the invisible border, the problem is not that Windows "thinks" that the window is off-screen. The window actually IS off-screen. The resizing border is part of the window.

This is the problem with these solutions of just shifting the windows so that you can't "see" the border. Suppose you place two windows side by side, and you remove the visible gap by shifting the windows to account for the border size. Now what you've effectively done was overlap one window on top of the other. Both windows still have their resizing borders. But you can only resize one, because the windows are not completely adjacent, but rather one is always overlapped on the other. You need to check the color of the titlebar to see which window has focus.