Windows 10 window borders

[stefansundin]

It seems Windows 10 includes some invisible window borders in GetClientRect, causing snapping to have a few extra pixels of distance to other windows (only seem to affect horizontally).

According to a stack overflow article, another function can be used:

DwmGetWindowAttribute(hwnd, DWMWA_EXTENDED_FRAME_BOUNDS, &rect, sizeof(RECT));

Unfortunately this window size cannot simply be used with MoveWindow, because it is smaller than what MoveWindow represents the window size as. So it will cause the dragged window to shrink by a few pixels every time it is moved.

The solution requires a lot of code to be reworked, so I won't fix it for v1.1.

[apatternjugglers]

Hi -thanks for your work on this great tool.
Just verifying that in my case it isn't just horizontal : by my measurements, it is 7px on the Left, Right and Bottom -but not the top. This is also reflected in normal Windows cursor/resize behaviour at the edges.
The result is that the top snaps tight to screen top, but 'loose' against the screen bottom and sides.
I look forward to a fix in v4.0!

[patricknelson]

Thanks for creating this issue @stefansundin and thanks a lot for creating AltDrag, I use it so often that I often find myself accidentally pressing Alt when attempting to move windows on computers that don't have this tool installed 😂

What would be your target version to fix this? I'm usually the type to just build it myself but I might pick up C just for this if it haunts me enough.

[stefansundin]

I'm not sure. My time is very limited these days so I won't even try to make a prediction. Sorry. :/

Patches are always welcome though. :) https://stefansundin.github.io/altdrag/doc/build.html

Btw, now that there's Bash on Windows, you should be able to use that instead of Cygwin. I will try to update the page with new instructions when I get around to it.

[daveola]

Love alt-drag. It makes my life so much easier.

But you've mentioned Bash on Windows, which I've just installed, and I'm sad to see that alt-drag doesn't work with either the Bash console (though it does work with the cmd console) - the bash console grabs alt drag to determine whether to do line-wrapping text selection or rectangular text selection.

And unfortunately it doesn't work when I launch an xterm with the ubuntu subsystem for windows either (using ming) though that's not much of a surprise.

[patricknelson]

@daveola Could you provide a screen capture (e.g. ShareX) of what your experience looks like when interacting with the console window?

[daveola]

The photo would just show the bash window, I don't know how to take a screenshot of a drag not working.

If I drag in the window, it does multi-line selection, as if you were just selecting a region of text.

If I alt-drag in the window, then it does a rectangle selection, where the text selection is a rectangle with no line wrap.

There's a session option that lets me switch which is the default selection type and which is controlled by alt, so it seems that the app is catching the 'alt' modifier. Is there any way to overide this?

[patricknelson]

Is there any way to overide this?

Hmm, not sure. Probably a silly question, but: Have you tried ensuring you launch AltDrag with elevated privileges?

[daveola]

I did not realize that was a possibility/fix!

Thanks much!

[loligans]

I appreciate everything you have done with this project. While I am not able to contribute to the project's code, because I don't know C. I am more than willing to put my money where my mouth is, if it means you get an opportunity to implement this feature. I understand you are busy so, I would happily donate $100 immediately if you agree to try an fix this. @stefansundin

[wngrtn]

I second that! I would be happy to give $100 in advance for you to take another shot at this.

[celynw]

This has been bugging me for years 😅, so I decided to have a go at fixing it!

Is it too much of a hack to lookup the border size difference and reverse it?
I tried the DWMWA_EXTENDED_FRAME_BOUNDS method and I experience what you say about the window shrinking every time it's moved.
But we can find the offset by comparing the results of this with GetWindowRect (also shown here).
Works a charm for me.
Also I think this only applies to the Aero snap? So the existing GetWindowRect calls don't actually need to be replaced.

EDIT: I haven't tried this on other DPI modes.

[wngrtn]

@celynwalters Is there a binary with your fix somewhere? I would love to give it a spin.

[celynw]

Try this!
(I compiled using WSL but seems to be ok).

[wngrtn]

Sweet. Works perfectly for me! Thank you!

[patricknelson]

For anyone curious to see the changes (without a PR): master...celynwalters:win10fix

[dnunes]

For anyone curious to see the changes (without a PR): master...celynwalters:win10fix

Hey. @celynwalters. Thank you very much for your work on this issue. Do you think you would be able to clean up your commit and create a PR? There seems to be some editor-stuff autofix going on (I think it changed some line endings for many files and removed some trailing spaces, which poluted the changeset).

I would be willing to help on creating a PR for this, but I don't have any C experience to try out new builds and make sure everything works. I'm sure this fix would help the usage A LOT for many people and it might be worth some minutes to create a formal PR and have it merged. Thanks again.

[celynw]

There seems to be some editor-stuff autofix going on

The reason I had these in here is because it wouldn't even compile for me unless the encoding was UTF-8 rather than UTF-8 with BOM. The encoding was inconsistent over the localization files.
But yeah, I guess that should be a separate commit.

I am pretty new to contributing to repositories which aren't exclusively mine.
I've made a pull request with the parts which only apply to this issue.
Unfortunately it's also very likely I won't have time to spend on this - If I get a chance I can build this tonight just to make sure it still works correctly.

[loligans]

@celynwalters Which binary should we use in your releases?

[celynw]

Ah, good point.
AltDrag-1.1.exe was the installer, AltDrag.exe was the binary. You could tell from the icons in Windows explorer.
I've updated their names now.

[loligans]

I just tried your branch and it does not appear to be fixed for me. I uninstalled my existing AltDrag instance and ran your AltDrag-1.1-installer.exe. What could I be missing or doing wrong?

[celynw]

Hmm, not sure.
As I've mentioned, I haven't tried this using a non-standard DPI scaling.
I have just used this installer to uninstall my current version, then reinstalled and it works fine for me. Maybe try doing that?
(It wasn't a totally clean install, at least the registry tweak remained, maybe also the saved settings)
Otherwise, it's possible the fix isn't so simple after all.

[loligans]

Microsoft is working on extending the Windows 10 shell with an application called, Power Toys. I recommend everyone to upvote this issue so Microsoft prioritizes Alt-Drag and Alt Resizing.
microsoft/PowerToys#269

[Avispa]

For everybody who was irritated as I was, this issue here is not solved on this repository here.

Therefore the issue here (for the repo of @stefansundin) shouldn't be closed because actually it is not (for the repo of @stefansundin again).

The binary with this fix argued here is found on https://github.com/celynwalters/altdrag/releases.

[RamonUnch]

This fix from @celynwalters is good but not complete, it does not take in account for all kinds of snapping, I made a fork that uses this DwmGetWindowAttribute function and applies it whenever applicable.
@Avispa My build fixes all invisible borders bugs under windows 10 as far as I can tell, give it a try if you still use AltDrag.

https://github.com/RamonUnch/AltDrag/releases/