My work in the last blog on “Why AutoHotkey for Students?” hatched a couple of personal AutoHotkey epiphanies. After all these years of using and writing about AutoHotkey, I continue to surprise myself with new discoveries. If I had read every word of the documentation (and possessed the ability to remember it all), then I may have understood these insights long ago. However, the AutoHotkey documentation contains a wealth of information which takes a great deal of time to digest.

I can’t fault the online manual because it covers nearly everything. Yet, it doesn’t always point out which bits are the most useful. When I discover a command or technique which significantly improves the operation of a script, I call it a “Best Practice.” Otherwise, I tend to keep using the same old techniques until something causes me to dig a little deeper. Last week presented just such an opportunity.

The biggest problem introduced by discovering these little gems involves going back and testing their limitations, then replacing all my old code lines with the better technique.

Speeding Up Text Insertion Routines

AutoHotkey Library Deal

As I worked on the CopyRef.ahk script for collecting selected text to a Notepad window, I noted how slowly the ControlSend command inserted the text into the collection window. It was like watching someone type—albeit at a fairly fast rate. Over the years, I’ve also noticed this slow text replacement in Hotstrings with long substitution sections. Extended Hotstring expansions tend to take their time—although they rarely interfere with my work.

I searched the Web and found that while many people wanted to speed up the Send command and their Hotstrings, none of the recommendations seemed particularly effective. (Most related to reducing the delay between characters.) However, while looking for streamlining options and after rereading the ControlSend command, I discovered:

If the target control is an Edit control (or something similar), the following are usually more reliable and faster than ControlSend:

Control, EditPaste, This text will be inserted at the caret position. , ControlName, WinTitle

Outside of this reference and the Control command page itself, I haven’t found Control, EditPaste cited anywhere else in the documentation. Yet, the command offers significantly improved performance for certain types of AutoHotkey scripts.

When I put the EditPaste, String command (found at the bottom of the Cmd, Value list on the AutoHotkey Control command page) in the CopyRef.ahk script, it blew my mind. After watching numerous character-by-character text insertions slowly dribble in, I found the immediate effect of EditPaste astonishing. I thought that I had discovered a panacea for slow substitution or insertion. Not so! While Control, EditPaste makes a dramatic improvement in the CopyRef.ahk script, its limitations prevent it from becoming a universal solution for slow text replacement.

The Send Command Versus the Control, EditPaste Command

It’s almost pure luck that the Control, EditPaste command worked for me. If I had not been using Notepad as the collection window in the CopyReg.ahk script, the command most likely would have failed—leading me to discard it as unusable. It’s certainly not a universal command. However, in certain AutoHotkey scripts, the Control, EditPaste command offers text insertion speed which you can’t get from Send or ControlSend. But first, let’s take a look at those two character-sending commands.

The strength of the AutoHotkey Send command resides in the fact that it works virtually everywhere in the Windows environment. It acts as a universal tool for directing keyboard characters to any active Windows program, Web browser, or utility. This capability makes it possible to replicate almost any keyboard action. The ControlSend command acts in a manner similar to the Send command except it can direct the output to any window—active or not.

The major downside for the Send command relates to its slow speed—inserting characters one at a time—as if typing. This retards the entire process. On the other hand, when operated from the keyboard, the paste key combination (CTRL+V) acts almost instantaneously—inserting in a flash the entire the Windows Clipboard contents. Even when using the Send or ControlSend command with the Windows Clipboard paste (i.e. Send, ^v), you can follow along as large sections of text appear one character at a time.

You can decrease this time lag by either adjusting the SetKeyDelay command to 0 or using the SendInput command (which doesn’t add any delay between characters). However, even those techniques don’t compete with a true manual keyboard paste.

Although not Clipboard dependent, the Control, EditPaste command acts like a true paste—as if you manually employed the keyboard for copy-and-paste operations (select text, CTRL+C, then CTRL+V in a new window or location). You see the results almost instantaneously. This command blows away the Send command by a wide margin. Unfortunately, the primary limitation of Control, EditPaste makes it a specialized tool. Only the ClassNN Edit (or Edit-like) control accepts data from EditPaste. If I had used almost any program other than Notepad for my reference collection window in the CopyRef.ahk script, the lightbulb may have never turned on.

Windows Programs and Edit Controls

It turns out that the majority of Windows programs don’t assign a ClassNN Edit control (i.e. EDIT1, EDIT2, EDIT3, …) to editing fields. As identified by AutoHotkey’s Window Spy or my WindowProbe.ahk tool, editing fields in most Windows apps use alternative ClassNN control names (e.g. ClassNN: Chrome_RenderWidgetHostHWND1 for a Google Chrome editing window such as a Facebook comment field)—if they use one at all. That means EditPaste won’t work with those programs.

Fortunately for me, Notepad’s first control (the default for EditPaste) is EDIT1. This made my initial test of replacing ControlSend with Control, EditPaste incredibly successful. However, virtually all of my other experiments replacing Send, ^v with an EditPaste statement bombed:

Control, EditPaste, %Clipboard%, , A

—even when I inserted the proper ClassNN of the editing window control. The only other Windows program which accepted EditPaste results was WordPad, but, even then, I needed the correct ClassNN name (RICHEDIT50W1)—which for some reason would randomly change the last digit during any given session (e.g. RICHEDIT50W1⇒RICHEDIT50W2).

Use Control, EditPaste for AutoHotkey GUI Controls

Other than the Notepad text editor—at least for copying text reference data—the best use for the Control, EditPaste command may be with any AutoHotkey GUI window. The ClassNN names for editing fields in GUI window default to EDIT1, EDIT2, EDIT3, etc. That means you can make good use of the speedy text insertion command in any AutoHotkey script which employs GUI Edit fields.

The input panes for the two tabs in Ryan’s RegEx Tester are EDIT1 and EDIT5, respectively.

The Control, EditPaste command is not limited to (nor dependent upon) Clipboard contents. The command can paste the contents of any variable (%variable%) into any ClassNN Edit control in any window. The syntax for EditPaste only requires plain text (without quote marks) for insertion and does not depend upon the Windows Clipboard—nor does it affect the contents of the Clipboard.

Tip: With the Send command, inserting a new line only requires a carriage return (`r) or linefeed (`n). However, the Control, EditPaste command requires both to recognize and insert the extra line. In the CopyRef.ahk script I used both to insert the additional line by evaluating the equivalent ASCII characters (chr(13) for the carriage return and chr(10) for the linefeed). Using both the carriage return (`r) and the line feed (`n) together in Send commands causes the insertion of two extra lines.

In the future, whenever I work on a script which sends text data to a GUI Edit control, I plan to use Control, EditPaste. But, in most cases, when working with other Windows apps, the universality of the Send command works better—even if a little slower.