Bug: Aero Snap: Holding Ctrl to restrict the cursor to the current screen doesn't always work about altsnap HOT 21 CLOSED

No specific reason, just general scurity reasons.

from altsnap.

Thanks for your feed-back, I would say the issue is closed...

from altsnap.

This bug that was specific to Ctrl is now fixed with 1.38

from altsnap.

Could you try with this one?
hooks.zip

from altsnap.

Still the same. Tested with File Explorer window. As suggested in #7 maybe increasing the aero-snapping activation areas is enough and so Ctrl wouldn't be as useful/needed.

from altsnap.

You can already increase the activation area in [Advanced] AeroThreshold, however it is on all the sides of monitors.
This bug will have to be fixed anyway.

from altsnap.

Thanks, that helped.

There is also an issue with pressing Ctrl to focus the window when dragging (doesn't matter if "Focus windows when dragging" is enabled or not, but easier to see it working with it disabled):

Say Firefox is in focus, I grab File Explorer with Alt (I'm actually using WinKey) to move the window, I then tap Ctrl to focus the window and move it across from one monitor to the other, but it behaves as if Ctrl is still pressed and so the window cannot cross the middle boundary. Pressing Ctrl again (sometimes twice) helps to "unstick" it and move the window freely. It doesn't happen every time, but it's there.

from altsnap.

Strange, I can not reproduce this, even though I use Win10 20H2 like you.
In your case the best workaround is to avoid pressing Ctrl for now...

Could you try with a different Keyboard?
I know this is very unlikely that this is the problem but in case it would be, that would be impossible to figure out the problem for me.

from altsnap.

I'm finding it hard to reproduce and not sure what I'm doing differently to make it happen. I think it's a timing issue perhaps, i.e. certain conditions are met at a specific moment. I'll have to pay more attention and see if I notice what is happening. Will let you know. Unfortunately, I do not own another keyboard.

from altsnap.

Try this...
hooks.zip

from altsnap.

Try this...
hooks.zip

It seems to have helped with the Ctrl key getting "stuck" as if held down I believe.

And I think I've understood what the original bug is about: if the order of keys is WinKey + Left-Click + Ctrl then drag, AltDrag performs as it should and the window never crosses the boundary between two screens. But if the order is WinKey + Ctrl + Left-Click then drag, the window crosses the border to screen2, and as mentioned, only after crossing does AltDrag think Ctrl is pressed as moving back to screen1 won't work, i.e. AltDrag is now responding to Ctrl correctly but it should've been doing so on screen1 too.

from altsnap.

Logically it should not work if you press Ctrl before clicking.
However there is a repetition of the keydown event by the keyboard, so it will be like hitting again ctrl after a fraction of second when you hold it down.
If my diagnostic is correct,, the problem is pure timing and if you press Win+Ctrl+LClick, WAIT (the time it takes for your keyboard to start repeating a key) and then try to change desktop and it should work.

Note:
The dirty workaround is to set your keyboard repetition delay to a short value.
Fix should not be hard.

from altsnap.

If my diagnostic is correct,, the problem is pure timing and if you press Win+Ctrl+LClick, WAIT (the time it takes for your keyboard to start repeating a key) and then try to change desktop and it should work.

According to my quick testing, you are correct: if I wait, the window is never able to cross the boundary.

Would it not be possible to check whether the Ctrl key is already pressed down when AltDrag grabs a window? This way it should be in immediate effect. Given the previous scenario, if "Focus windows when dragging" is disabled, grabbing the window with Ctrl already held, should also fix the delay in bringing the window to the front (due to the key-repeat delay).

Something I've just noticed is that certain windows that are currently in focus, e.g. WizFile / Process Hacker v3.x nightly build will not allow you to grab a window behind them: The first attempt always brings the background window into the foreground / focus, and the second attempt behaves as expected. I tried blacklisting them just to see if it'd help but it did not.

from altsnap.

Would it not be possible to check whether the Ctrl key is already pressed down when AltDrag grabs a window? This way it should be in immediate effect. Given the previous scenario, if "Focus windows when dragging" is disabled, grabbing the window with Ctrl already held, should also fix the delay in bringing the window to the front (due to the key-repeat delay).

Yes it should, and if should be done for next release.

For the window issue, Have you tried to run AltDrag elevated?

from altsnap.

For the window issue, Have you tried to run AltDrag elevated?

That was the solution, thanks! I had wondered what purpose elevating the program was for. I guess it's worth always running with admin privileges as I can imagine it may solve a few other "bugs" I may encounter in the future.

Also, the dialog box that appears when checking the "Elevate to administrator privileges" could mention that instead of disabling UAC (to avoid the prompt), a task can be setup via Task Scheduler to automate this (i.e. run the program at startup with admin rights, no prompt shown).

from altsnap.

Under Windows XP+ a program can be running as a different user while still having the window displayed on the current user desktop. This means that for any program that runs elevated, you need to have elevated privilege in order to interact.

In general I recomend not to use elevated mode unless you do use several of this kind of windows in your daily workflow.
You can use the menu to elevate the program if you it in the middle of your workflow.
My program does not ues the Task Scheduler, but it seems a good idea if you want to disable UAC prompt without disabling UAC. The message was kept fromOriginal AltDrag. And I myself usually run AltDrag non-elevated.

from altsnap.

Okay. Fair points. Is there any specific reason you don't recommend running AltDrag elevated, other than the typical reasons of security and such?

from altsnap.

It seems that I can not fix this issue, and it is related to a very special treatment of the Ctrl key.
If I change the key to Shift it makes no problems.
This attached version can use Shift as well as Control to restrict movement to the current monitor.
Shift should work flawlessly but Control should have similar problems to the older versions.
give it a try...
hooks.zip

from altsnap.

It works exactly as you say. And the order of WinKey>Shift or Shift>WinKey doesn't matter either; it always succeeds at locking to the current monitor.

from altsnap.

This will be in the next release. If I find a solution for Control, I will apply it.
I do not see drawback to using Shift to restrict to current monitor instead of Control.
Control has to be kept separated from Shift for focusing windows but maybe that could be its only application and I could disable it for monitor restriction?
What do you think?

from altsnap.

Ergonomically, I think it works well for the left hand e.g. thumb on Alt, ring-finger on Shift, and pinky finger can tap Ctrl to focus if need be.

Since using Ctrl for monitor restriction has this flaw, I agree with your thinking.

from altsnap.