Windows 8.1 issue - AltDrag seems to work only a portion of a window

[grpmpk]

I have a Surface 1 Pro with Windows 8.1 installed with the latest updates. For some reason, AltDrag has issues with Windows 8.1:

1. I can Alt+LeftClick and move the window so long as I am clicking the left side of the window, that is, as long as the mouse cursor was hovering over less than ~50% (very approximate) of the width of the window. Seems to have the same issue too with the height: I have to be clicking on the top side of the window.
2. Consequently, if I alt-drag beyond the approximate 50%, say the lower right hand of the window, drastic effects can be seen, e.g., the icons on the desktop would be dragged away from their position.

It's hard to explain by words and I don't have the means to record by video at the moment. For the time being, is my description of the issue clear? If not, please let me know so I can clarify.

[stefansundin]

That's a curios issue. I do not have access to a Surface to try it out myself, and it is working fine for me on my Windows 8.1 computer. If anyone can figure out how to reproduce it on a normal desktop setup, I'd be happy to try to fix it.

Try changing your display settings, e.g. DPI and other things. Maybe you'll find what setting makes it happen. Thanks for reporting!

[grpmpk]

You were right about the DPI. In Windows 8.1, by going into Control Panel > Appearance and Personalization > Display, and setting the "Change the size of all items" all the way to the right towards Larger (which is the Recommended Size, according to the corresponding thumbnail), I was able to replicate the scenario I've described reliably.

When I set it all the way to the left towards Smaller, AltDrag works as I expected. However, all my window elements are smaller, which is non-ideal.

I only have one Windows 8.1 machine (my Surface 1 Pro), so if someone else can replicate this scenario on their own Windows 8.1 box, I (and I think the developer too) would appreciate it.

[Aldaviva]

I think I'm seeing related behavior.

Environment

• Windows 8.1
• Desktop computer, not Surface Pro
• Samsung U28D590 4K monitor (3840 x 2160)
• Default settings for font scaling and "Change the size of all items"

Observations

• When I change my resolution to 1920 x 1080, AltDrag behaves normally.
• When I change my resolution to native 3840 x 2160, AltDrag exhibits two issues:
  • If I Alt+click outside the top-left quarter of a window's region, the click is ignored.
  • If I Alt+click inside the top-left quarter of a window's region, AltDrag thinks I started dragging from a different position in the window so the window is shifted by hundreds of pixels when I first start dragging. After starting to drag, it behaves normally.

[Aldaviva]

Workaround

1. Right-click on AltDrag.exe > Properties > Compatibility tab
2. Check the box for "Disable display scaling on high DPI displays"
3. Restart Alt-Drag

Now Alt-Drag behaves correctly no matter where in the window I start dragging from, even at native resolution.

[stefansundin]

Thank you for the workaround, I will link it from the website. I hope I can fix this permanently for the next version.

[grpmpk]

Thanks for the workaround, I can confirm that the workaround works for my Surface Pro 1, hooray!

However, and sorry to continue being the bearer of bad news, but if I use DOUBLE monitors, the workaround only works for the Surface Pro 1 screen, and not the other monitor (even with the workaround).

I imagine that this is a separate, but related, use case?

[Aldaviva]

I would characterize Windows 8.1's support for multiple displays with different pixel densities as "infuriating."

[LordJZ]

I couldn't agree more.

[rog1039]

Thanks, worked for me too!

[sethbc]

Issue persists in Windows 10, but would note the fix works as well (I'm running two 4K monitors @ 150% scaling, so haven't tried different pixel densities).

[Brog33]

Ahh finally. This workaround should be out there, not hidden in the issue tracker. Tell about it in the docs/installer? More and more people get 1440p+ screens now and altdrag cocks up if DPI-scaling isn't disabled.

[stefansundin]

It is mentioned on the website, but you are right of course, if I can't fix the problem for the next version, then I'll probably add a note in the installer. Sorry.

[LMLB]

Tutorial: Writing High-DPI Win32 Applications

[dmwyatt]

The recommended fix does not exactly work on the latest version of Windows 10.

"Disable display scaling on high DPI displays" is no long an option. There's new options.

You have to select "Application".

[Tahutipai]

Note: as of 2017-August this program returns positive on 3/64 tests on virustotal.com - returns positive for "Win32.Trojan.WisdomEyes". Any comments from author?

[stefansundin]

@Tahutipai I am not surprised, since AltDrag uses keyboard and mouse hooks (and HookWindows, disabled by default, does even more invasive stuff). Many antivirus manufacturer uses heuristics to try to detect programs that does suspicious things. However, heuristics can't tell you for sure if something is malicious.

Here's the two scans:

• https://virustotal.com/#/file/68f145aed758a51b638632c4b3fb61343827a72a7f96ef8f4fba64c117451a02/detection
• https://virustotal.com/#/file/c45f48cf4e7f00f63f3e236c0226242d38392eb8dc2c85e1f6bed578b68c08de/detection

In the second one you can clearly see that it is some kind of heuristics by the name, "W32.eHeur.Malware12". The first one just says "Win32.Trojan.WisdomEyes.16070401" which is less clear.

Anyway, the only thing I can say is that it's clearly bogus. Please compile it yourself if you are worried, there are instructions here: https://stefansundin.github.io/altdrag/doc/build.html

In any case, thanks for reporting it! If I get the time I might submit false positive reports to the antivirus vendors.

[roblarky]

Try adding this to the manifest:

`

<windowsSettings>
  <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true/pm</dpiAware>
  <!-- legacy -->
  <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">permonitorv2,permonitor</dpiAwareness>
  <!-- falls back to pm if pmv2 is not available -->
</windowsSettings>

`

[davebrny]

thanks @dmwyatt, i havnt been able to use altdrag since i got a surface book last year. such a simple fix!

[MattSturgeon]

I've tried the updated workaround in this comment however I'm still reproducing the issue.

This is my config:

I've been trying to set up a build environment so that I can try @roblarky's suggestion however its not been going very well! Don't really want to install a full cygwin when I already have WSL and two mingw installs (one came with git).

---

Edit: ended up setting up cygwin and @roblarky's suggestion works perfectly. I've opened a PR to try and get his changes merged.

[softyoda]

Hi, i have a 16/9 38402160 screen in 125% windows scale and a 21/9 38401600 screen in 100% windows scale. The program have issues sometimes.

I don't know how to add to manifest (is it the altdrag.ini or something else ?) thanks.

[MattSturgeon]

@softyoda probably easiest to install the patched version I linked to in #99 (under the Testing heading).

You can also see how the manifest is changed by looking at the diff on that PR, but you'll have to build the project yourself if you want to apply the changes yourself (hence why I recommend the prebuilt fixed download)

[krizajb]

I am having two 4k screens, one using 250% scale and another 175%. It does work better with the prebuild fixed download, but it's still far from usable :( The main problem I am dealing with is, that when moving from one screen to another it can randomly resize the dragged window. From my observations it always makes it larger. The issue isn't always reproducable.

[softyoda]

On my side, I stopped using the software because it doesn't work as it should, I had to restart the session to restore the proper functioning of the explorer.
And this even with the prebuild fixed download.

[krizajb]

Unfortunately this is my best bet so far. Every other option I've tried so far works even worse. I did experience the same issues you are describing with the latest stable build. None with the prebuild fixed, but I've only been using it for an hour :P
PS: Did you find any alternative that works without any issues for our case?

[MattSturgeon]

Have you seen the AutoHotKey scripts liked here? They behave similar to AltDrag but are implemented completely differently, so manage to avoid many of the hidpi scaling weirdness and some other bugs.

[sparebytes]

I just tested the AutoHotKey script with two monitors at different DPIs. Unfortunately windows resize to become larger whenever they touch the border of the two monitors.

[krizajb]

Same here, I've posted my end results here. I've tried many AHK scripts used from days where there was no such thing as 4K, obviously none worked :) So far AltDrag works a lot better then any AHK script I've tried or attempted to understand and tweak myself :)

[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

[Remington012]

My Windows 10 instance is also scaled by 125%. The dialogs in Windows 10 now look like Matt's screenshots above, but I needed to use the settings from Gilles's post to resolve the issue.

So happy to finally have a solution to this issue!

[rbdone]

These settings are working for me in Windows 10 May 2020 update (build 2004) with a 4k monitor

[RamonUnch]

For information I am keeping a fork of AltDrag alive here, where I fixed DPI related issues a while back, alongside other issues related to Window 10 and Windows 8.x, on which I extensively test it.

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

Apparently the work on the power toy implementation stopped.

[bufferUnderrun]

@RamonUnch your version is just perfect and solve all issues that suffer the old altdrag version. I use your but hard to find it on google and how is your relation with the official project is not clear. The original project is still not update, maybe it's time to fly on your own, rename-it and YOLO !

[RamonUnch]

Thanks for your feedback @bufferUnderrun, I opened a new issue to discuss a New name for the project

[vsrawat]

I confirm odd behavior of AltDrag for SAMSUNG 32 inch 4K Ultra HD Monitor LU32J590UQWXXL

I was previously on LG 18.5 inch 1360x768 monitor and AltDrag worked well for years on various OS.

This week I got this UHD monitor, no other change, and AltDrag seems to be completely broken on W8.1 and w10 both 64 bits.

When I click my Altdrag activation setting, and my cursor jumps to some other open window, and doesn't move any window at all, and even leaves windows beyond the screen.

I have tried various control key combination but couldn't make it to work.

Display in w8.1 is set to 150% and I am satisfied with what I see so no point for going for a smaller size.

I landed to this thread from google search. it matched with my issue so posting confirmation here instead of opening new issue.

Thanks.

[vsrawat]

Workaround

1. Right-click on AltDrag.exe > Properties > Compatibility tab

2. Check the box for "Disable display scaling on high DPI displays"

3. Restart Alt-Drag

Now Alt-Drag behaves correctly no matter where in the window I start dragging from, even at native resolution.

That solved everything on w8.1-64 bit in a jiffy. Good old Altdrag is back.

Thanks a gig.

[nenesekai]

On Windows 11 the text has changed a bit but it's the same.

Go to the properties > compatibility tab > change high DPI settings > override high DPI scaling behavior

Scaling performed by set to Application

then it should work as expected :)

[woctezuma]

For information I am keeping a fork of AltDrag alive here, where I fixed DPI related issues a while back, alongside other issues related to Window 10 and Windows 8.x, on which I extensively test it.

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

Apparently the work on the power toy implementation stopped.

Very nice! Using your fork is another workaround. :)
The pro is that I would not have to change properties of the executable if I were to install it on another computer.

That being said, I experience the same conflict with VS Code when using either AltDrag or AltSnap:

• Following links: alt-click ❌ ctrl-click ✔️ microsoft/vscode#141238

Not sure if there would be a fix for that weird issue.

Edit: Fixed with: 🥳

• Please allow alt-click in windows RamonUnch/AltSnap#126 (comment)

[stuaxo]

@RamonUnch can we upstream your changes to here if @stefansundin is up for it ?

[RamonUnch]

We already had this discussion here: #124
Now my fork was renamed to AltSanp and went such a distance from AltDrag that there is not much sense in merging it into the original AltDrag. I did submit a couple of pull requests to fix some annoying bugs on but Stefan is focused on other projects.