Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
grpmpk opened this issue Jul 4, 2014 · 31 comments · May be fixed by aar0ndev/altdrag#1
Open

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

grpmpk opened this issue Jul 4, 2014 · 31 comments · May be fixed by aar0ndev/altdrag#1

Comments

@grpmpk
Copy link

@grpmpk grpmpk commented Jul 4, 2014

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
Copy link
Owner

@stefansundin stefansundin commented Jul 4, 2014

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
Copy link
Author

@grpmpk grpmpk commented Jul 6, 2014

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
Copy link

@Aldaviva Aldaviva commented Jul 31, 2014

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
Copy link

@Aldaviva Aldaviva commented Jul 31, 2014

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
Copy link
Owner

@stefansundin stefansundin commented Jul 31, 2014

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

@grpmpk
Copy link
Author

@grpmpk grpmpk commented Jul 31, 2014

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
Copy link

@Aldaviva Aldaviva commented Jul 31, 2014

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

@LordJZ
Copy link

@LordJZ LordJZ commented Jul 31, 2014

I couldn't agree more.

@rog1039
Copy link

@rog1039 rog1039 commented Jan 20, 2015

Thanks, worked for me too!

@sethbc
Copy link

@sethbc sethbc commented Aug 1, 2015

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
Copy link

@Brog33 Brog33 commented Oct 7, 2015

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
Copy link
Owner

@stefansundin stefansundin commented Oct 7, 2015

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.

@dmwyatt
Copy link

@dmwyatt dmwyatt commented Jul 13, 2017

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.

Windows 10 DPI DPI options for compatibility mode

You have to select "Application".

@Tahutipai
Copy link

@Tahutipai Tahutipai commented Aug 15, 2017

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
Copy link
Owner

@stefansundin stefansundin commented Aug 15, 2017

@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:

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
Copy link

@roblarky roblarky commented Jan 26, 2018

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
Copy link

@davebrny davebrny commented Sep 18, 2018

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

@MattSturgeon
Copy link

@MattSturgeon MattSturgeon commented Dec 20, 2018

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

This is my config:

2018-12-20 20_18_04 - issue 7

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
Copy link

@softyoda softyoda commented Mar 8, 2019

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
Copy link

@MattSturgeon MattSturgeon commented Mar 8, 2019

@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
Copy link

@krizajb krizajb commented Sep 1, 2019

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
Copy link

@softyoda softyoda commented Sep 1, 2019

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
Copy link

@krizajb krizajb commented Sep 1, 2019

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
Copy link

@MattSturgeon MattSturgeon commented Sep 1, 2019

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
Copy link

@sparebytes sparebytes commented Sep 1, 2019

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
Copy link

@krizajb krizajb commented Sep 2, 2019

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
Copy link

@loligans loligans commented Sep 9, 2019

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
Copy link

@Remington012 Remington012 commented Jan 8, 2020

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
Copy link

@rbdone rbdone commented Jul 31, 2020

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

image

@aar0ndev aar0ndev linked a pull request that will close this issue Oct 22, 2020
@RamonUnch
Copy link

@RamonUnch RamonUnch commented Feb 11, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.