Prevent Win+Ctrl+Alt+Shift hotkeys from opening the Office dialog in Windows 1903

[ciantic]

Hello,

I've discovered that with Windows 1903 update the Microsoft has added some global hotkey:

Hold Win+Ctrl+Alt+Shift and then release it will open a Office dialog.

This means that most of the special shortcuts done with Autohotkey are affected, which happen to use that combination. The combination is important because it used to be a safe set of keys we could use for own shortcuts. The shortcut appears to be created by explorer.exe, it stops working if you kill it.

Possible fixes are: Find a way to disable the Office hotkey now globally bind by Windows to Win+Ctrl+Alt+Shift or a new way to make special keys.

As per se this is not AHK bug, but it will affect a lot of scripts I suspect. There is also thread: https://www.autohotkey.com/boards/viewtopic.php?f=76&t=65224

[lexikos]

That's interesting, but I don't get what you're hoping to achieve by posting it in the Bug Reports forum.

I've never wanted to physically or artificially use that combination of keys.

[ciantic]

Actually I thought AHK has a set of hacks to override the other quirks of Windows, by adding a way to disable that would be just one more. I can imagine it's similar problem as overriding Alt+Tab, I don't think it's normally overridable without hacks.

However I do accept this is not bug as such, but real annoyance. This combination is widely used within QMK community, because it's the only combination of modifiers that was unused. So we could use it as own key in keyboard. It was even named as "Hyper" key in QMK / Ergodox EZ keyboard configurator ( https://github.com/qmk/qmk_firmware/blob/master/docs/feature_advanced_keycodes.md ).

What I suggest is a find a way to disable it, and post here as it's found.

[lexikos]

But why in Bug Reports? You want help doing something, there's a place for that. This is not a bug, never mind "as such" or "per se".

AutoHotkey does not have any kind of "hack" to override Alt+Tab, and certainly does not override it by default - you must define a hotkey. There is no reason for AutoHotkey to block this or any other system hotkey by default.

[ciantic]

Okay, can we just move this topic?

To me AHK has always been this magic tool that can override any and all hotkeys, including Windows key, Alt+Tab etc. so when I couldn't override the Office key it seemed to me like a bug.

And I thought it's similar problem as Alt+Tab, since when I bind Alt+Tab the normal behavior is overridden, however if I bind Win+Ctrl+Alt+Shift it still throws me the office dialog (or opens PowerPoint or Word depending what you used e.g. +W or +P).

It is different behavior if you think it like this: you can define alt+tab and it overrides the default behavior, but you can't seem to be able to define Win+Ctrl+Alt+Shift or Win+Ctrl+Alt+Shift+P or Win+Ctrl+Alt+Shift+W which are overridden by explorer.exe no matter what I do from AHK.


Maybe this is closer to feature request, or general discussion.

[lexikos]

I moved and renamed the topic.

---

AutoHotkey is a user-mode application, not a keyboard driver. We can detect keyboard events only because the system notifies us when they occur. The system always knows that a key is pressed before AutoHotkey does, but the system has multiple levels of processing - including keyboard filter drivers, low level system hotkeys, keyboard hooks, registered hotkeys, keyboard messages posted to the active window, and default processing of those messages. Some hotkeys are implemented in a way that AutoHotkey cannot override; this includes Ctrl+Alt+Del and Win+L, but does not include Win+Ctrl+Alt+Shift.

Alt+Tab and Win+Ctrl+Alt+Shift are not really comparable, because you are not trying to use Tab as a modifier key.


This hook hotkey triggers when you press Alt+Tab, and therefore blocks Tab from any processing that occurs after the keyboard hook, but does not block Alt.

Code: Select all

ListHotkeys
!Tab::MsgBox

This registered hotkey triggers when you press Win+Ctrl+Alt+Shift (Shift must be pressed last). The hotkey is registered with the system, and the system notifies us when it is pressed. Obviously, that means the Shift keypress is seen by the system's hotkey pressing, which would be the logical place for the Office hotkey to be implemented. On Windows 1903, the system apparently launches Office and notifies us that the hotkey was pressed.

Code: Select all

ListHotkeys
#^!Shift::MsgBox

This hook hotkey triggers when you press Win+Ctrl+Alt+Shift, and therefore blocks Shift from subsequent processing, but not Win, Ctrl or Alt. The system's hotkey recognizer sees only Win, Ctrl and Alt, so does not activate the Office hotkey.

Code: Select all

ListHotkeys
$#^!Shift::MsgBox

Of course, since the system's hotkey recognizer does not see Shift, registered hotkeys will only be triggered if they use Win, Ctrl and Alt but not Shift (e.g. #^!a). AutoHotkey's keyboard hook behaves the same; it sees Shift, but knows that the logical state of Shift is "not pressed" (because the hotkey blocked it).

So in short, AutoHotkey does not handle Alt+Tab and Win+Ctrl+Alt+Shift differently; it handles combinations which are already registered hotkeys differently from combinations which are not. You will get more consistent results if you have #UseHook in your script.

[lexikos]

As for Win+Ctrl+Alt+Shift+P or Win+Ctrl+Alt+Shift+W, there is nothing to override, because these are not standard hotkeys. If you define them as hotkeys, AutoHotkey will block P or W, just the same as it would block P or W in ^p:: or +w::.

The problem is that when AutoHotkey blocks P in #^!+p::, the system only sees Win+Ctrl+Alt+Shift, which is the Office hotkey.

By contrast, the hotkeys $!p:: and $#w:: will automatically mask the Alt/Win key. "Masking" the key merely means sending a key as a replacement for the one which was blocked, so that the system will see that the modifier key was used in combination with another key. You can do it manually:

The Start Menu (or the active window's menu bar) can be suppressed by sending any keystroke. The following example disables the ability for the left Win key to activate the Start Menu, while still allowing its use as a modifier:

Code: Select all

~LWin::Send {Blind}{vk07}

Source: #MenuMaskKey - Syntax & Usage | AutoHotkey

Do you see where I'm going with this?

Spoiler

Code: Select all

#^!Shift::
#^+Alt::
#!+Ctrl::
^!+LWin::
^!+RWin::
Send {Blind}{vk07}
return

[ciantic]

Thanks! So everyone trying to disable the Office key, here is the snippet of yours that does it:

Code: Select all

#^!Shift::
#^+Alt::
#!+Ctrl::
^!+LWin::
^!+RWin::
Send {Blind}{vk07}
return

I think I get this now. However I wouldn't have figured the code above, since it was not intuitive to me, I only tried to disable it by trying to bind this:

Code: Select all

#^+!::

Which didn't work.

[lexikos]

What you wrote is Win+Ctrl+Shift+Exclamation-mark. Modifier symbols must be followed by a key name or character, otherwise they're not modifiers.

[steve_g]

As for Win+Ctrl+Alt+Shift+P or Win+Ctrl+Alt+Shift+W, there is nothing to override, because these are not standard hotkeys. If you define them as hotkeys, AutoHotkey will block P or W, just the same as it would block P or W in ^p:: or +w::.


Do you see where I'm going with this?

Spoiler

Code: Select all

#^!Shift::
#^+Alt::
#!+Ctrl::
^!+LWin::
^!+RWin::
Send {Blind}{vk07}
return

lexikos- thanks for that. It did not occur to me to do it this way. And bravo on how patient you are.

[lexikos]

By using Process Monitor, I have found another way to prevent Win+Ctrl+Alt+Shift from opening the Office app or website: make it open some other program.

Just set the default value of the registry key HKCR\ms-officeapp\shell\open\command to the path of a program, or the name of a program which the shell can locate, such as cmd. In my case, the HKCR\ms-officeapp\shell and HKCR\ms-officeapp\shell\open keys did not exist (presumably because I removed the Office app), so I created them first. Use HKCU\SOFTWARE\Classes\ms-officeapp\shell\open\command instead to affect only the current user.

This also affects what happens when you run ms-officeapp:. For the other Office apps, I'm guessing some other "ms-" URI schemes would be used, like "ms-powerpoint".

Unfortunately, it seems the Office shortcut only uses this registry value to locate the Office app, and does not use any parameters that may be set. It always passes the parameter Officekey. cmd just ignores it, but notepad gives a warning that "Officekey.txt" does not exist.

[BGM]

I'm just trying to get win+K to work without opening the office app.
https://www.autohotkey.com/boards/viewtopic.php?t=72503#p316266

I don't care about any office apps at all. I'd like to disable them all but leave winkeys like win+R and win+E for run and explorer.

[BGM]

You know what? I think something else is going on here.

Since win+k kept launching the office app, I tried changing the hotkey to other combinations.
Every single hotkey I tried to use to send the global hotkey ctrl+alt+shift+k to open keypass would launch the office app.
However, if I try to use ctrl+alt+shift+k itself, it opens keepass without launching the office app.

So I changed the ahk hotkey to win+2. Now win+2 does not launch the office app. But it does if I assign it to keepass.
It seems like it's just keepass. Maybe keepass is doing something weird with it's own global hotkey?
I have all sorts of other global hotkeys set with ahk and they all work just fine. But keepass always triggers the office app when I try to use ahk to trigger it's hotkey. This happens even if I change keepass's global hotkey.

The whole point of this is I want to use the win key to open the keepass window, and keepass doesn't let you set the win key. So I have an ahk global hotkey to send the keepass global hotkey.

[j4hangir]

As for Win+Ctrl+Alt+Shift+P or Win+Ctrl+Alt+Shift+W, there is nothing to override, because these are not standard hotkeys. If you define them as hotkeys, AutoHotkey will block P or W, just the same as it would block P or W in ^p:: or +w::.

The problem is that when AutoHotkey blocks P in #^!+p::, the system only sees Win+Ctrl+Alt+Shift, which is the Office hotkey.

By contrast, the hotkeys $!p:: and $#w:: will automatically mask the Alt/Win key. "Masking" the key merely means sending a key as a replacement for the one which was blocked, so that the system will see that the modifier key was used in combination with another key. You can do it manually:

The Start Menu (or the active window's menu bar) can be suppressed by sending any keystroke. The following example disables the ability for the left Win key to activate the Start Menu, while still allowing its use as a modifier:

Code: Select all

~LWin::Send {Blind}{vk07}

Source: #MenuMaskKey - Syntax & Usage | AutoHotkey

Do you see where I'm going with this?

Spoiler

Code: Select all

#^!Shift::
#^+Alt::
#!+Ctrl::
^!+LWin::
^!+RWin::
Send {Blind}{vk07}
return

Thank you, using {blind} successfully overrode this stupid global shortcut.

Who's coming up with these ideas at Microsoft anyways?

[valdus]

I know this is an old thread, but it is the first that comes up on Google for "autohotkey office key", and I wanted to present an extension for newer users, and a simple alternate solution as well. [Mod edit: Link fixed.]

This post relates to the "Office" key found on newer Microsoft keyboards, as well as the "Emoji" key next to it. These keys replace the typical positions of RWin and AppsKey, respectively.

If your goal is to simply disable the Office key from doing anything when pressed, the code given above by lexikos will work. It will not block the hotkeys which use all four modifier keys (the office key) - e.g. Office+W will still open Word, and the shortcuts for Excel, LinkedIn, Yammer, OneDrive, etc. will all continue to work. If you want to disable them or override that, you can do them individually override them, like this: #^!+W::return. Note this will not affect the Emoji key.

Here is the code from lexikos again, for easy reference:

Code: Select all

#^!Shift::
#^+Alt::
#!+Ctrl::
^!+LWin::
  Send {Blind}{vk07}
return

I removed the RWin line from the original code, as it is redundant - the Office key only sends LWin.
Personal note: On my system, I found I don't need the Send {Blind}{vk07} line - simply ending with "return" was enough to stop Office from launching. Your mileage may vary.

---

However, I found two downsides to the method above. First, it simply renders the key useless - I want to restore my missing Apps key! Second, the Office key does not actually act like a modifier key, at least not on my Microsoft Bluetooth Desktop keyboard - pressing and holding the key will spam LControl Down, LAlt Down, LShift Down, and LWin Down repeatedly until the key is released (at which point one Up is sent for each). This might be a peculiar behaviour of the Bluetooth keyboards, as it seems all the individual modifier keys behave the same way. Regardless, holding the key down results in rapidly reaching the default #MaxHotkeysPerInterval limit since it acts as 4 different keys at once.

A more permanent and less troublesome method that does not require AHK is to modify the Windows registry. This registry key will make the Office key run a useless command, effectively disabling it. It will, again, not block the individual hot keys - it only removes the loading of the Office app. I take no credit, I found this solution on multiple web sites.
- Run: REG ADD HKCU\Software\Classes\ms-officeapp\Shell\Open\Command /t REG_SZ /d rundll32
- To reverse it, run: REG DELETE HKCU\Software\Classes\ms-officeapp\Shell (the Shell registry key/folder does not exist originally, so it can be completely removed)

---

Either of the methods above will make pressing the Office key do nothing. But what if we want more? New Microsoft keyboards replace the common RWin and Apps keys with Office and Emoji. I, for one, heavily used the Apps key.

I present my solutions:

All-AHK solution based on lexikos' code, convert both Office and Emoji keys to Apps/Menu key

Code: Select all

; Prevent Office key from functioning (in conjunction with next code segment)
#^!Shift::
#^+Alt::
#!+Ctrl::
  Send {Blind}{vk07}
return

; Convert Office key into Apps key
^!+LWin::
  Send {Blind}{vk07}
  KeyWait, Control
  KeyWait, Alt
  Send, +{F10}
return

; Convert Emoji key into Apps key
#^!+Space::
  Send, +{F10}
return

Solution using the registry edit, convert both Office and Emoji keys into Menu/Apps key

Code: Select all

;;; Convert "Office" and "Emoji" key presses to "RWin" and/or "Menu" key presses.
;; REQUIRES REGISTRY ADDITION TO PREVENT OFFICE APP FROM OPENING
;; Run: REG ADD HKCU\Software\Classes\ms-officeapp\Shell\Open\Command /t REG_SZ /d rundll32
;; To reverse (and stop using this script), run: REG DELETE HKCU\Software\Classes\ms-officeapp\Shell

^!+LWin::
  KeyWait, Control
  KeyWait, Alt
  Send, +{F10}
return

; Convert Emoji key into Apps key
#^!+Space::
  Send, +{F10}
return

I wanted to convert Office to act as a fully functional RWin, but I couldn't make it work - too much interplay with various modifier keys and the OS...

[lexikos]

@valdus
If you scroll up, you should see that I mentioned the registry edit already.

However, I found two downsides to the method above. First, it simply renders the key useless

That's not a downside - that was the purpose, and the first step in making the Office key do something useful. I was going to say you can just add more code if you want the key to do something else, but I see you already did that. So I fail to see what you found troublesome about that method. The other method, editing the registry to make the office shortcut run rundll32, also "renders the key useless", so what you say is confusing.

On my system, I found I don't need the Send {Blind}{vk07} line - simply ending with "return" was enough to stop Office from launching.

Depending on the version of AutoHotkey, it might be sending a mask keystroke (Ctrl by default) to prevent the Alt or Win key from showing a menu (even though that would never happen because of the other modifier keys being held down). Current and past versions of AutoHotkey are not specifically designed to suppress the Office shortcut. The exact conditions for masking Alt or Win have changed a few times, most notably in v1.1.27.

pressing and holding the key will spam LControl Down, LAlt Down, LShift Down, and LWin Down repeatedly until the key is released

Are you saying that it spams those events immediately, without the normal delay of key-repeat? Otherwise, that sounds like normal key-repeat, which applies to modifier keys the same as most other keys. If you hold LCtrl, it will repeat LCtrl-down until you release LCtrl or physically press some other key. If you hold AltGr, it will repeat LCtrl-down and RAlt-down because it is really a combination of those two modifiers. The Office key is a combination of all modifiers, so it repeats them all.

Normally you wouldn't notice that the modifier keys repeat, because they don't normally have any immediate visible effect. If you press two physical keys in combination, only the last one will repeat. If you press and hold the Office key and then any other physical key (perhaps even a real modifier key), I'd bet the Office key won't (continue to) repeat even if you release the other key immediately.