Comments (21)
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 withCtrl
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.
Related Issues (20)
- Windows always snap, no matter AltSnap settings.
- Feature Request : Autoborderless zone-snapped windows (minus blacklist) ? HOT 1
- Resize windows from center - like osx [Feat] HOT 5
- Cant seem to clear shortcut keys - keyboard tab [v1.63] HOT 8
- Feature request : Somehow be able choose overlapping zones ? HOT 8
- Feature request : reload config explicitly option in systray context menu HOT 2
- [bug?] Snapping after Alt-Tab doesn't work. HOT 3
- Fix minimize action HOT 1
- [question] how to bring window to front after Alt-Click-MouseMove? HOT 2
- Intermittently stops interacting with windows HOT 3
- Move to left/right/top/bottom zoone limitation HOT 2
- Compatibility with Komorebi HOT 5
- Add UIAccess flag to allow managing admin windows without running as admin HOT 10
- Chocolatey packaget not updating HOT 10
- PiercingClick doesn't work on windows11? HOT 5
- Cursor can't left-click until a right-click is issued HOT 22
- Centering a window is misaligned
- A separate blacklist for showing Window lists/Changing Windows
- Highlight selected zones before snapping HOT 1
- Allow resizing while alt+left click held down HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from altsnap.