Beginning Tips for Writing AutoHotkey Scripts (Modular Independence of HotKeys)

This is the second part of the series for beginners about how to visualize AutoHotkey script writing. The first part discusses HotStrings and how each operates as a separate feature independent of the rest of the script. This concept in scripting is a little unusual in programming languages (and may seem sloppy), but makes adding hotstrings for text replacement/expansion easy.

That’s because AutoHotkey scans the entire script, pulling out and setting up each hotstring before processing the main script. These hotstrings can appear anywhere in the script, although they are less likely to cause other problems if they appear after the auto-execute portion in the beginning of the script and are placed toward the end of the AHK file.

AutoHotkey HotKeys are processed in a manner similar to hotstrings—each one creating an independent module. This means that numerous hotkeys can be included in the same script without interfering with each other—or any hotstrings, as discussed last time.

AutoHotkey HotKeys

A hotkey can be one key or a combination of a number of keyboard keys which when pressed simultaneously initiate an action. They are simple to set up in AutoHotkey using a format similar to the hotstring format (needing only one set of double colons rather than two ). Hotkey combinations are always pressed all at the same time, whereas hotstrings are always typed sequentially rather than simultaneously.) Simple one-line commands or entire applications can be called up with a hotkey combination. This simple example taken from the AutoHotkey online documentation uses a hotkey combination to open Windows Notepad:

#n::
  Run Notepad
Return

The format for hotkeys is the designated key combination followed by double colons (::), then the lines of command code followed by the Return command. In this example, once the script is loaded the keys WIN+n (#n) become the hotkey combination which when simultaneously pressed opens Windows Notepad. (In AutoHotkey, the number sign (#) represents the Windows logo key.)

This is a self-contain snippet of code and can appear almost anywhere in a script. The snippet of code is sealed with the Return command at the end. Unless it is a one-line hotkey command (e.g. #n::Run Notepad), it is important to include the Return command at the end of most hotkey snippets. If AutoHotkey does not see a terminating Return, it will continue to process whatever code may follow—even if it is not an intended part of the hotkey snippet.

Simple One-Line HotKeys

Just as one-line hotstrings can be added to scripts at almost any location (as long as they don’t appear in the auto-execute section or within another self-contained module), one-line hotkeys have that same level of independence. If you merely want to disable a Windows key combination, then add to your script that combination followed by a double colon and the Return command:

!F4::Return

My addition of this hotkey combination to my master script was a reaction to a problem I had with certain Windows apps unexpectedly closing without saving my current work whenever I accidentally pressed ALT+F4 (!F4). (Freaked me out!) In this example, whenever, ALT and F4 are pressed at the same time nothing happens. The default behavior for the program (closing the window without saving) is blocked. (This technique, including how to isolate the blocking to one particular program, is discussed in the e-book AutoHotkey Applications.) If another combination needs to be blocked, merely add another line:

^F4::Return

The CTRL key is represented in AutoHotkey by the caret (^). The primary problem with this approach to blocking hotkeys is that although it does nothing, it also tells you nothing. You may not know that you did something you didn’t want to do. I modified the lines as follows:

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

Each line continues to block the recalcitrant keys, but now it tells you what you did using the MsgBox command.

Note: The Return command is not used with one-line hotkeys.

Adding Power to Your Windows Editing with HotKeys

In the previous installment of this beginning blog, I showed how a multi-line hotstring could act as a hotkey—except that the keys are pressed one after the other rather than at the same time. Normally, unless you want text replacement/expansion, hotkeys are a better alternative to hotstrings since they don’t require you to enter screen input to activate the action. Because you must select text first, the following example of a hotkey routine which converts text to all lowercase letters would be impractical as a hotstring action:

^l:: ; Convert selected text to lowercase
  OldClipboard:= Clipboard
  Clipboard:= ""
  Send, ^c ;copies selected text
  ClipWait 0
  StringLower Clipboard, Clipboard
  Send %Clipboard%
  Sleep 500
  Clipboard:= OldClipboard
Return

This hotkey (CTRL+l) changes selected text to all lower case letters. This is convenient for reformatting those messages that people send you in all capital letters. (“Why all the caps? You think I’m hard of reading?”) After saving the old value of the Windows Clipboard, the snippet copies the highlighted text from any edit window to the Windows Clipboard, converts it to lowercase using the StringLower command, then Sends back the converted text to replace the selected text in the edit window—later restoring the original value to the Clipboard. (This example is discussed in more detail in the e-book A Beginner’s Guide to AutoHotkey.)

The above is another example of a self-contained module. It can appear virtually anywhere in a script without affecting the rest of the code. If you already have a master script which contains your most used AutoHotkey apps, then you can include this one by adding the hotkey module to the end of the AHK file. It could just as easily be added to your AutoCorrect file. Similar to the way hotstrings are processed by AutoHotkey, the hotkey code is loaded when the file is first loaded but is not activated until the hotkey combination is used.

Adding Entire Apps to a Master Script with HotKeys

As long as there is nothing in an app which will affect other code in an AutoHotkey script, it can usually be added to a master script by enclosing it with a hotkey combination followed by the AutoHotkey app code and enclosed with the Return command:

^!g::
   [Put AutoHotkey code for app here.]
Return

In many cases, this is all that you need. However, sometimes these scripts require setup in the auto-execute section at the beginning of the master script or conflict with other apps in the same script. In those situations, you may need to move the setup portion from the hotkey module to the auto-execute section of the master file or in the second case modify the script to eliminate conflicts. This can get a little complicated for the novice script writer—at least until one gets more experience under their belt. There is an alternative.

In these conflicting situations, the modularity of the app can be maintained by merely assigning a hotkey combination to run the entire app as a separate process. Then there will be no conflict since it is loaded as a new program. The following example is a compiled AutoHotkey script which creates new, temporary hotkeys. It is loaded with a hotkey assigned in the master script:

^!H::run, C:\Users\%A_UserName%\AutoHotkey\InstantHotkey.exe

(This example can be found in the “Free AutoHotkey Scripts and Apps” Web page and is available for download.)

While the hotkey combination is assigned when the script is initially scanned, the AutoHotkey app is not loaded until the hotkey is actually activated This adds another possible level of modularity by isolating individual scripts from all the other modules. The app will load as a separate instance unaffected by the master script.

Next time, we look into the modularity of labels (or subroutines), which, although they are also independent snippets of code, are treated differently from hotstrings and hotkeys by AutoHotkey.

* * *