*          *          *

New to AutoHotkey? See “Introduction to AutoHotkey: A Review and Guide for Beginners.”

*          *          *

Writing an AutoHotkey script can be as simple as adding one line to an AutoHotkey text file with the AHK extension. The line:

:*:j@::jacksmail@gmail.com

instantly expand the typed key sequence “j@” to “jacksmail@gmail.com” whenever it is entered into any form or edit box on a Windows computer—including Web pages. (The main AutoHotkey program must be installed first. See “Installing AutoHotkey and Writing Your First Script.” ) If you want to add another text expansion feature, then you merely add another single line of code:

:*:c@::computoredge@gmail.com

The two keys “c@”, each time they are typed, are automatically expanded to “computoredge@gmail.com” replacing the original hotstring sequence. Each text expansion line is a self-contained module that it is independent of other code and can technically appear anywhere in a script. When the script is loaded, AutoHotkey will find all of the hotstrings, regardless of location in the file, and set them up as an automatic text expansion/replacement units.

This concept of modular independence is important to AutoHotkey script writing. Each of these examples is a separate AutoHotkey app, but, while they can appear anywhere within a script and still work, the inappropriate placement of this line of code may interfere with other aspects of a script.

Modular Independence

While there is usually a set of code lines which run at startup (the auto-execute section) where its placement in the script is very important, most AutoHotkey snippets are broken up into independent modules which are either immediately set up for use (text expansion and hotkeys) or stored for access at a later time (subroutines/labels and functions). Each module is a self-contained snippet of code which can appear virtually anywhere in a script except in the auto-execute section or inside another module.

Think of a script as being composed of these sealed bricks which each do a specific job. If the code you’re including is a self-contained module, it will operate independently of the rest of the script when called upon. This means that you can include a virtually unlimited number of these bricks in a script—as long as they do not interfere with the auto-execute section in the beginning of the script or another module. This means that it’s usually best to place these modules at the end of the file or include them in a separate file with the #include command—also best located toward the end of the file.

Each text expansion line (also called a HotString) is a complete module. As an example, the AutoHotkey AutoCorrect app is composed of thousands of lines of hotstring code—each one an independent module with does text replacement/expansion. The order of these lines does not matter to AutoHotkey—although there should be some organization for the convenience of the user. You can add more hotstrings (a double colon :: followed by the hotstring, followed by another double colon :: and the replacement value) to anywhere in the file. Each line is its own complete action.

For the beginner, hotstring replacement is one of the simplest uses for AutoHotkey and the coding is very forgiving. The only caution is that if you use the same hotstring more than once, only the last one in the script will be operational.

If you want to create more sophisticated hotstrings, such as replace a short hotstring sequence with entire paragraphs or do calculations before the replacement, then the one-line module will not do the job.

Multi-Line HotString Expansion

While it is exceptionally convenient to use one-line hotstring modules, there are times when a single line of code is not enough to get the job done. In those instances, there are additional ways to seal a snippet of code into an independent module. (As other areas of AutoHotkey are explored, we will see that the notation for creating these new independent bricks is also used with many other pieces of the language.) The first is multi-line text expansion. Turning the replacement into a paragraph (or set of paragraphs) is merely a matter of enclosing the replacement paragraphs with parentheses (…). From the online documentation:

::text1::
(
Any text between the top and bottom parentheses is treated literally, including commas and percent signs.
By default, the hard carriage return (Enter) between the previous line and this one is also preserved.
    By default, the indentation (tab) to the left of this line is preserved.

See continuation section for how to change these default behaviors.
)

(This example was reduced in font size to prevent onscreen word wrap.)

The hotstring is removed and replaced by the enclosed text exactly as it appears between the two parentheses. This hotstring is another self-contained module which can be placed almost anywhere in an AutoHotkey script.

HotString Action Module

The next method for creating a multi-line hotstring module is by terminating it with the Return command. The Return command is commonly used to seal hotkey and subroutine (label) modules. When Return is added to the end of the hotstring snippet, the code becomes an independent module. From the online AutoHotkey documentation:

::btw::
  MsgBox You typed "btw".
Return

In this case, typing “btw” opens a MessageBox which contains You typed “btw”. This can be any number of lines of code initiating almost any AutoHotkey action. The primary requirements are that the code must start on the next line after the hotstring and the module must be terminated with the Return command.

View an AutoHotkey Script as a Set of Modules

Most people new to programming just start writing code which immediately executes when run. While this may be effective, as scripts get longer and more involved, there is a greater possibility that one snippet of code will interfere with another. The more modular a script is made with independent snippets of code, the less likely that conflicts will occur. One of the advantages of AutoHotkey is that much of the language is already modular (hotstrings and hotkeys). Then, other features can be made more self-contained by creating subroutines (labels) and user-defined functions.

A common error is placing a module inside this continuous sequence of code. Often, a module will stop the execution of the code—especially hotstring and hotkey commands—causing the script not to function properly. Therefore it is usually best to place these sealed bricks toward the end of the script file.

The advantage to using independent modules of code is that it is much easier to both combine various features and debug problems. Next time, I will explore hotkeys as independent modules in AutoHotkey scripts. Understanding the modularity of hotkeys will make it easier to use them in any app.

*         *          *

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

Want to learn more about how AutoHotkey can power up your Windows computer? See the AutoHotkey books available at ComputorEdge E-books.