System-Wide Windows Hotkey Doesn't Always Work

Hi,

I'm not sure why, but sometimes, some system-wide hotkeys that I've configured to override standard Windows hotkeys don't work. Rather, they sometimes work, and sometimes fail. I'm using Windows 8.1 x64.

For example...
[ul][li]Win-K is configured as a system-wide hotkey in Opus to launch Keepass, but it still brings up the Devices list.[/li]
[li]Win-F is also configured as a system-wide hotkey, and it does bring up Everything.exe (as configured), and not Windows Find.[/li][/ul]
These two hotkeys are configured the same way and active at the same time. One works and the other doesn't.

When I experiment with AutoHotkey, sometimes it does a similar thing--it spontaneously stops working, and the standard Windows hotkey function "takes over." Though with AutoHotkey, I can click on it in the system tray and then its hotkey starts working again. It's almost as if I'm bringing it "forefront" and so it captures the hotkey event first. It doesn't work so well in Opus to do this--not even to restart Opus or unregister/re-register the hotkey. Maybe they use different methods to get system hotkeys, like a keyboard hook versus RegisterHotkey. Or maybe it's always the same ones that don't work and I just haven't noticed due to experimenting with AutoHotkey at the same time? Well, Win-K and Win-F or both standard Windows shortcuts in 8.1. I'm not sure why one could be overridden but another couldn't. FYI I just tried Win-1 and Win-2, and they both work fine for the moment. Win-K still doesn't.

Anyway, have you ever seen this problem where overriding some Windows hotkeys doesn't work or stops working? Any advice?

Nirsoft's HotKeysList is a good way of checking and debugging what Hotkeys are up to.

Is the different behaviour dependent on which program's window is currently active?

Or perhaps on whether an elevated (UAC) program is active or a normal program?

The NirSoft tool may not give a full picture for hotkeys which replace standard Win-x hotkeys, by the way. Replacing those has to be done in a special way.

Not that I can tell.

I'm not sure what you mean. I do have UAC at the lowest setting if that matters.

OK, I tried out setting almost every key on my keyboard. For Opus, using RegisterHotKey, it seems like these keys are unavailable and don't work with the Win key. I guess.

=
U
I
O
P
S
H
K
Z
X
C
N
,
.
]
'
TAB
CAPS
SCROLL LOCK
NUM /

L was a special case as I couldn't even put it into the key configuration dialog (since it locks Windows).

Also -- (I'm not sure how to edit my own post) -- I found that Ethervane ActiveHotkeys works pretty well to identify which hotkeys are in use. The nirsoft tool didn't work as well.

Though neither of them tell you which process registered the hotkey. That would be helpful information.

Did you try making them system-wide? Some can only be overridden that way, although it is possible some can't be overridden at all, if Windows captures them at a low-level before applications like Opus can see them. (We have some facilities for working around that issue, but it's always possible they work with some Win hotkeys and not others, depending on the system components which are handling the keys.)

They are all system wide hot keys.

AutoHotKey uses a method that works most of the time and does work to override these keys in Windows.

It's strange that some can be overridden and some can't.

OK, I discovered a method that works for some more of those keys. It's a workaround that allows Win+S to work as a system-wide hotkey, but still fails with the likes of Win+C and Win+K.

In regedit, add a string value called "DisabledHotkeys" under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced. Set the value to the list of hotkeys you wish to disable in Windows. For example, setting it to SN disables Win+S and Win+N.

AutoHotkey works with Win+C and Win+K, though. I think they must use a keyboard hook (SetWindowsHookEx) when RegisterHotkey fails. I did just figure out today that it fails when an elevated window is in focus when you press the Win+x shortcut--unless AHK is run as Administrator. That might be why AHK fails for me sometimes (as described above) and not other times.

Anyway, I think that there is more work to be done on the Opus side to properly work around Windows' capriciousness with Win+X shortcut keys. I'll probably just keep using AHK for now.

It sounds like that is also true of AHK, and probably all tools that let you do this.

Alternative point of view: It may be best to simply avoid trying to repurpose low-level system hotkeys for your own things. There are millions of other key combinations to choose from (both with and without the Win key) and, as you've seen, the low-level ones cannot be changed reliably, even by tools which are dedicated to that kind of thing.

Opus can override normal-level ones like Win+E which are handled by the desktop shell (although you only have to do that if you don't want Win+E to open the Computer folder, which is what the Windows hotkey does by default). (Ones handled by the "metro" shell may be more problematic. That would include Win+C and Win+K).

Some of the low-level ones are handled at a driver or kernel level. Some would introduce security concerns if they could be replaced (Win+L and Ctrl+Alt+Del, for example). So some of those hotkeys are things the operating system rightly protects against hijack.

[quote]Alternative point of view: It may be best to simply avoid trying to repurpose low-level system hotkeys for your own things. [/quote]That's a fair point. I am surprised to see it espoused by a representative of the company that makes Directory Opus, though, considering what Directory Opus does and means to its customers--a way to replace and reprocess existing Windows framework into something better, faster, more usable, and tailored to the customer.