Block Annoying Computer Shortcuts, Plus Identify Active Windows and Programs with Windows Spy

Override Unwanted Windows Shortcuts with AutoHotkey Hotkeys

Some Windows system and program shortcuts are annoying. Others are just plain dangerous. In the last blog, I talked about the problem with CTRL+F4 and ALT+F4 when used in either Google Chrome or Firefox Web browsers. (I’m not sure about Microsoft Explorer because I almost never use it.) Both of those key combinations immediate close either the window or active tab. If you accidentally hit one of those shortcuts while doing some online editing or data input, you run the risk of losing all your  work—depending upon when you last backed up. In most other programs (e.g. Notepad), you get a warning to save before the window closes, but not those browsers. From my perspective, those shortcuts are totally unnecessary. Fortunately, these unwanted Windows features can be blocked with AutoHotkey. (I’ve added CTRL+W to that list of dangerous Web browser closing shortcuts.)

One great (although often overlooked) feature of AutoHotkey is that you can block annoying or dangerous Windows shortcuts with Hotkeys. In AutoHotkey,we usually think in terms of initiating an action with a Hotkey, rather than blocking one, but these keyboard combinations can also work as very important shortcut overrides.

The AutoHotkey documentation has a special page devoted to overriding built-in Windows shortcuts. That page covers most of what you can do to eliminate unwanted key combination. However, I hesitate to recommend the first technique which involves changing the Windows Registry and blocks all Windows key shortcuts. Never mind the dangers involved in tinkering with the Windows Registry—there are many Windows shortcuts you may want to keep. For example, I use WIN+E regularly to open a File Explorer window. Plus, I think the Windows Registry fix  only applies to key combos using the WIN key. I recommend using AutoHotkey to override shortcuts. It gives you much more control and flexibility than messing with the Windows Registry.

Basic Shortcut Blocking

There are a number of ways to change or block shortcut key combinations. In our example, we want to stop the operation of CTRL+F4, ALT+F4, and CTRL+W. The simplest AutoHotkey technique is to merely define the overriding combination with the basic Hotkey format and no action command to the right of the double colon:

^W::
!F4::
^F4::

(The four basic Hotkey modifying keys (CTRL ^, ALT !, WIN #, and SHIFT + are discussed in the last blog.)

While this approach works, it’s worth noting that any Hotkey definition left blank will take on the action of any Hotkey immediately following it on the next line. This isn’t a problem if none contains any action, but it is far safer to include the Return command:

^W::Return
!F4::Return
^F4::Return

This seals off each definition ensuring that none will be affected by other Hotkeys. Even better, add a command so that you’ll get notified when you hit any of those unwanted key combos:

^W::MsgBox Oops! You pressed CTRL+W
!F4::MsgBox Oops! You pressed ALT+F4
^F4::MsgBox Oops! You pressed CTRL+F4

The MsgBox command informs you that you’ve been saved from possible doom. This both makes each Hotkey definition self-contained as well as providing feedback.

While this approach solves the basic problem, there could be programs where you want the shortcuts to work when not in the browsers. With AutoHotkey you can designate both when the Hotkey is active and inactive. There are a number of different ways to do it.

Conditional Hotkeys

There are various methods for blocking Hotkeys only when particular programs are running. The first is to make the Hotkey check the active program window each time it executes. The following example blocks the Hotkey if the active window is a Google Chrome window:

$^W::
 IfWinActive ahk_class Chrome_WidgetWin_1
    Return 
 Send ^W
Return

This is a modified form of the example found in the AutoHotkey “Overriding or Disabling Hotkeys” page.

The advantage to this technique is that in real time it quickly checks the active window with the IfWinActive command, then, if the active window is Google Chrome, it terminates the routine with the Return command. Otherwise, it executes the same Hotkey combination using the Send command. This active window id approach is especially useful when you want the Hotkey to perform different actions depending upon which window or program is active. It offers more flexibility than some other options.

Tip: In this case, it’s important to use the $ prefix in the Hotkey definition. This prevents the Send command from executing the same Hotkey combination inside the routine. If allowed, it would theoretically cause an infinite loop, although AutoHotkey traps it as an error (as shown).

The downside to this approach for creating conditional Hotkeys is each program and each Hotkey needs the blocking action and the alternative action within the Hotkey code itself. AutoHotkey has another approach for creating context-sensitive Hotkeys using #Directives which isolate the blocking action to specific Windows programs without needing alternative action code. It also eliminates the infinite-loop risks with the Send command. (This is a topic for the next blog.)

Identifying Active Windows and Programs

For a beginner, the most confusing line in the above code is probably the parameter for the IfWinActive command (ahk_class Chrome_WidgetWin_1). This tells us that a Google Chrome window is active, but how do we know that? Now is an opportune time to talk about how to identify windows and programs.

Windows Spy

An important question is “How do we know what parameter to use with the IfWinActive command?”

Once installed AutoHotkey includes a utility program called Windows Spy. The easiest way to access the utility program is through the green AutoHotkey icon found in the System Tray on the right side of the Taskbar when running and testing an AHK script.

Right-click on the icon to open the context menu. Select Window Spy from the list. Window Spy will open in the always-on-top mode.

Finding the Right Window

Once Window Spy has launched it displays specific information about the active window. To read the info for a particular program left-click on any window making it active.

The window data immediately appears in Window Spy. The class of the windows is found on the second line under the heading Window Title & Class. The highlighted section (ahk_class Chrome_WidgetWin_1) is the ahk_class for Google Chrome. This is an unchanging designation for any Google Chrome window. Window Spy will return the same ahk_class for a Chrome window every time. This is important because there are other types of AHK ids which do change when another program or window is launched or opened (e.g. ahk_id, ahk_pid, etc). These ids are helpful for tracking open windows and processes, but their discussion is beyond the scope of this blog.

WindowProbe.ahk Script

An alternative method for finding window titles and class is a short AutoHotkey script I wrote call WindowProbe.ahk which includes only the information I’ve found most useful—although no mouse cursor location coordinates are offered. It is available from the ComputorEdge AutoHotkey Download page in the file WindowProbe.zip. The download includes both the AHK and the compiled EXE file.

This script creates and displays a Tooltip window which follows the mouse cursor. The Tooltip displays the data from any window it hovers over. CTRL+WIN+T to toggle the Tooltip on and off. CTRL+F12 copies the information to the Windows Clipboard.

This short script is easily modified to uncover any other pertinent data (cursor coordinates?).

Context-Sensitive Hotkeys

The second (and usually preferred) method for creating conditional Hotkeys is through using AutoHotkey #Directives to set up context-sensitive Hotkeys. Any Hotkey can be made context-sensitive without resorting to any complex coding. This is done with the #IfWinActive directive. While it looks similar to the IfWinActive command, #IfWinActive works in a totally different manner. Indeed all of the directives which are preceded with the hash mark (#) operate differently from the commands.

It’s important to understand what AutoHotkey does when it encounters a #directive —and when it does it. Many beginners get confused about the difference between commands and #directives—making the debugging of AutoHotkey scripts much more difficult. Therefore, I’ll give more foundation for understanding #directives, but save this discussion for next time.