Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Windows 8.1 and win-key shortcuts oddity


  • Please log in to reply
4 replies to this topic
jimhoyle
  • Members
  • 22 posts
  • Last active: Jan 20 2017 04:42 PM
  • Joined: 11 Oct 2009

In Windows 8.1 I am using ClassicShell and AutoHotkey to make the life better. There is a quirk I don't understand. I have put my own shortcut to #W (Win+W) for example. Without AutoHotkey that would be Search Settings (by Windows 8). And indeed, it does do Search Settings even if I have my ahk script loaded. But here's the thing: The Windows 8 behavior only overrides my ahk binding if some of the following programs is active: SublimeText, UltraEdit, Notepad. I don't know if it coinsidence that they are all text editors.

 

My question is: Why do some programs let the Windows 8 win-key bindings override the ahk win-key bindings and some not? What is the factor determining which programs do this and which not? (I could see nothing special in program Properties for example, e.g. no Compatibility modes are used.)



hachi
  • Members
  • 330 posts
  • Last active: Jul 14 2015 02:09 AM
  • Joined: 24 Jan 2010

that is just the way win shortcuts work, autohotkey by default assigns hotkeys through registerhotkey(), and some windows keys can take precedence over them this way. you can work around that by specifying #usehook at the top of your script, or using the $ prefix to define certain hotkeys. for example this is the method I use to intercept and disable the common ones, so that they all just trigger a return:

#usehook
;intercept windows binds
#l:: ;lock comp, cannot be overridden
#u:: ;access center
#left:: ;move win to left
#right:: ;move win to right
#up:: ;win maximise
#down:: ;win minimise
return

you could also disable most of them completely (besides #L and the ones above) with a regedit,

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"NoWinKeys"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"NoWinKeys"=dword:00000001


jimhoyle
  • Members
  • 22 posts
  • Last active: Jan 20 2017 04:42 PM
  • Joined: 11 Oct 2009

Thank you for the good answer. Indeed, putting those two entries in registry and rebooting results in winkey-shortcuts not being forced anymore. However, I'm not satisfied because in WinXP and Win7 there was no problem using #arrow-combos for own purposes. I still want to do so. Is there a hack imaginable? I can think of two ways: 1) somehow forcing AutoHotkey to detect #arrows in all situations (Win8) or 2) making the app behave in the more AutoHotkey friendly way (#left doesn't work in Notepad but in IE it works, why?).



jimhoyle
  • Members
  • 22 posts
  • Last active: Jan 20 2017 04:42 PM
  • Joined: 11 Oct 2009

Ok, apparently the same problem extends also to the CapsLock key. In some programs (e.g. the mentioned Notepad) CapsLock is not available for AutoHotkey either. In other words, I can use my CapsLock AutoHotkey script only when Notepad and a bunch of other applications are NOT active windows. There has got to be a solution for this, it is a major problem.



jimhoyle
  • Members
  • 22 posts
  • Last active: Jan 20 2017 04:42 PM
  • Joined: 11 Oct 2009

Ok I resolved this. It was the category of "Administrative programs" that would override AutoHotkey. For me, the best solution was to not try to run AutoHotkey.exe from the Windows Start-up folder but start it with Task Scheduler instead. It is mandatory to have AutoHotkey.exe Properties / Compatibility / [x] Run this program as an administrator, that makes the shortcuts work in programs such as Notepad. Problem was, AutoHotkey would not load from the Start-up folder if the "Run this program as an administrator" option was ticked.

 

This is how I was able to start AutoHotkey with Task Scheduler, while AutoHotkey.exe is ran as an administrator:

 

Task Scheduler -> Task Scheduler Library -> Action / Create Basic Task -> Name:AutoHotkeyStart -> Trigger: When I log on -> Start a program -> The path for Autohotkey.exe -> Finish. Then find the new task in the list and double click to adjust the options. Make sure you've got General / [x] Run only when user is logged on, [ ] Run with highest privileges. The user you have on "When running the task, use the following user account" field has to be an administrator. Make sure Actions / double click the Start a program entry / "Start in" is the path where your AutoHotkey.exe is. Because if you have your AutoHotkey.ini there, it won't be found if this is not set. At Conditions / Power, make sure it's [ ] Start the task only if the computer is on AC power. Check also Settings / [ ] Stop the task if it runs longer than.. And probably good to have General / Configure for: Windows 8.1.

 

Then I just added that #UseHook to my script's beginning. Everything seems to work fine now, #Left and everything.

 

There is one more workaround I had to use: Using the method above, the tray icon for AHK did not show. Because Task Scheduler forced it hidden even the [ ] hidden was unticked. So I had to create AutoHotkeyRun.vbs. I put Task Scheduler to load this vbs instead of the exe directly, and this vbs would load the exe in turn. That way the tray icon appears normally. This is content for the vbs file I did (AutoHotkeyRun.vbs):

Dim objShell
Set objShell = WScript.CreateObject( "WScript.Shell" )
objShell.CurrentDirectory = "C:\Tools\AutoHotkey"
objShell.Run("""C:\Tools\AutoHotkey\AutoHotkey.exe""")
Set objShell = Nothing

Edit: This method turned out imperfect. After a while Windows will still override the keypresses. I haven't found out yet what causes this reverting. The AutoHotkey tray icon looks fine, but still AutoHotkey wouldn't get the keypresses after a couple of sleep and resumes or so. When this happens, also the tray icon / Open / View / "Key history and script info" would not get the keypresses any more. I will be seeking for a solution still.