Every So Often You Slap Yourself on the Side of the Head When You Realized How Simple It Really Was!

Maybe it’s just me, but do you ever find yourself spending hours (or possibly days) on a problem only to later find an easy solution staring you right in the face? Possibly, you developed a working solution—but it was  a little convoluted. Maybe, if you had leaned back, relaxed, and rethought the situation, you would have seen your error and never charged off into the coding bog. When the truth comes out, it’s always a little embarrassing.

*          *          *

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

*          *          *

When I make these types of mistakes, it’s even worse, because I’ve already publicized my supposed solutions. Now I’m forced to backtrack and eat my own words—or, at the very least, correct the record. Maybe there was someone who caught my misunderstanding, who, out of pity, didn’t want to shove it in my face. Or, perhaps, since most people who read this blog are novices, it didn’t occur to anyone that there was a simple answer to the problem. In any case, I confess.

My Lack of Insight

While editing my upcoming book on AutoHotkey Hotstrings, I was re-reading the portion which originally appeared in an earlier blog (Part 3 of the Hotstring series). I was discussing the implementation of a Hotstring for expanding the string ahk to the word AutoHotkey without affecting input of the extension .ahk. I had set up two activating Hotstrings .ahk and ahk—respectively appearing in order in the AutoCorrect file. First in line was .ahk—which allowed no change—and took precedence over the ahk⇒AutoHotkey  expansion:

:B0:.ahk::           ;If found, nothing
:C:ahk::AutoHotkey   ;If lowercase

These two lines were designed to allow me to reference the extension .ahk without expanding it to .AutoHotkey—as discussed in Part 2 of the series. (Using the order of Hotstrings code lines in the AHK file to establish precedence is an important technique.) The problem was that whenever I used the extension with a filename it expanded to AHKScripFile.AutoHotKey.

At this point, I misunderstood the problem. I thought that the preceding dot was causing the Hotstring to reset, thus making the following ahk active and expand to AutoHotkey. (While that thought was not totally wrong, the supposition started me down an alternative road.)

I seemed that I needed to “…build an action Hotstring which differentiates between typing ahk and .ahk (a dot plus ahk). The problem with the previous solution was the dot caused the Hotstring to reset forcing filenames such as AHKScripFile.ahk to expand to AHKScripFile.AutoHotKey. In order for the HotString to prevent this, it needs to check the character before the ahk to determine whether or not it is a dot.”

In Part 3 of the Hotstring series, I presented an action Hotstring which does just that. It goes through a number of gymnastics to identify the leading dot and determine if the string should remain untouched. Operationally there is nothing wrong with the routine and there are a number of learning points found in the script. (If fact, there are some situations where the approach may be quite useful—as in an example I include in the new book.) The problem is that it’s just not needed here!

My error was in not realizing that the .ahk Hotstring only worked as a standalone word—generally with a space before the dot. The real problem was that when the .ahk became part of another word as in AHKScripFile.ahk, the second Hotstring activated. All I really needed to do was add the Hotstring question mark ? option to the first line of code which causes the string to activate even if inside another word . Then there would be no reset when the first dot was encountered. The first .ahk Hotstring (which does nothing) alway  fires and supersedes the second ahk Hotstring:

:B0?:.ahk::
:C:ahk::AutoHotkey

Duh! Now .ahk will not expand to .AutoHotkey, even when used as the extension of a filename.

Possibly, if I had merely reviewed the Hotstring options (which I had just discussed in previous blogs), I never would have proceeded down that obscure alternative path into the weeds. (I plan to leave that scripting diversion in the book since there is some useful information found in the discussion, but I will add the appropriate warnings.) While I didn’t mind the trip myself, I always knew that it might be a bit too involved for the novice script writer.

I dare save anyone who has done a little scripting occasionally drives off-road into rough areas only to discover later that the signs were relatively obvious. The temptation is to delete the  unneeded code as if it had never existed. In this case, I’ll leave it untouched as a testament to time I spend wandering through a script.