As Signs of the Impending Release of AutoHotkey V2.0 Crop Up in the Online Documentation, Questions Arise About Our Legacy Scripts
I start by admitting that I have no special insight into AutoHotkey V2.0. I’ve had no contact with anyone who has the answers. I base all my thoughts on information freely available in the online documentation, forums, and other AutoHotkey sources. You might consider my words rank speculation—although drawn from my years of working with AutoHotkey V1.1. Since I written so many AutoHotkey books, you could even say that I hold a vested interest in the current version of AutoHotkey. In spite of all that, I offer this blog as an aid to current and future AutoHotkey users in their version decisions.
Why AutoHotkey Version 2.0?
As stated in the online documentation, “AutoHotkey v2 aims to improve the usability and convenience of the language and command set by sacrificing backward compatibility.” V2.0 simplifies things by removing many traditional AutoHotkey commands and replacing them with clearer, more consistent functions.
Note: As an important caution, while AutoHotkey V2.0 continually marches forward toward eventual release, it currently resides in alpha testing and you should not yet install it as your primary AutoHotkey program—unless you understand exactly what you’re getting into.
The words “sacrificing compatibility” may strike terror into your AutoHotkey plans. If you’ve amassed a considerable number of scripts written for V1.1, then the task of converting to V2.0 (which drops numerous traditional commands) looks daunting. However, you have nothing to fear. When AutoHotkey V2.0 arrives as a full release, only you will decide if it works for you. If you desire, you can stick with the old version of AutoHotkey without any impact. If you opt to venture into V2.0, then the change probably won’t cause as much pain as you might imagine. It’s unlikely that anyone will attempt to force you in one direction or another.
With an eye to the future, while maintaining AutoHotkey V1.1 compatibility with the traditional commands, the keepers of the code have added new alternative functions and syntax offering the same results as the original command. These expanded optional methods add to our understanding of what’s coming down the road—although increasing possible sources of confusion.
For example, when used in an AutoHotkey script, what’s the difference between the var = cow (traditional) and var : = “cow” (the alternative) expression? They both work in the current version. These redundant methods create a duality in AutoHotkey V1.1 offering different cohabitating syntax for doing the same thing. AutoHotkey V2.0 aims to simplify the language by reducing it to a standard set of operators and functions while eliminating the confusing traditional format.
Difference Between AutoHotkey V1.1 and V2.0
The redundancy in the current version of AutoHotkey can induce mental discombobulation—especially when debugging a script. For example, you find dual methods for setting and evaluating variable. Use var = 123 for assignment and %var% for evaluation in the traditional—now called legacy—method. Include var := “123” and direct variable name evaluation (var without percent signs) for the expression method. After dropping the legacy traditional operators, V2.0 only uses only the second expression (:=) method.
Note: The %var% operator commonly used in pseudo arrays (e.g. array%a_index%) changes to %expr% in V2.0 for creating names or partial names of variables or functions.
The V1.1 includes multiple If conditional commands:
IfEqual, Var, Value (same: if Var = Value) IfNotEqual, Var, Value (same: if Var <> Value or if Var ! Value) IfGreater, Var, Value (same: if Var > Value) IfGreaterOrEqual, Var, Value (same: if Var >= Value) IfLess, Var, Value (same: if Var < Value) IfLessOrEqual, Var, Value (same: if Var <= Value) If Var IfInString
While the current version of AutoHotkey supports many of the new V2.0 functions, you’ll find many other commands which lose support when replaced with the equivalent function. For example, the StringReplace command now supports two different formats:
OutputVar := StrReplace(Haystack , SearchText [, ReplaceText, OutputVarCount , Limit := -1]) ; Requires [v1.1.21+] StringReplace, OutputVar, InputVar , SearchText [, ReplaceText, ReplaceAll?]
(Command lines word wrapped with line continuation for display purposes—unchanged in V2.0.)
Only the StrReplace() function added with AutoHotkey [v1.1.21+] remains in V2.0. If you would like to prepare for V2.0, you can start using the StrReplace() function now rather than the legacy StringReplace command.
However, more powerful commands such as the GUI (Graphical User Interface) command, do not currently offer a parallel function. Ultimately, V2.0 replaces GUI with a GUI object creating function GuiCreate(). For example, create a name input GUI with:
Gui := GuiCreate() Gui.Add("Text",, "Please enter your name:") Gui.AddEdit("vName") Gui.Show
For many users of AutoHotkey, this creates a troubling issue. Most scripts written for one of the V1.x versions (and including GUIs, menus, etc.) won’t operate under V2.0. While in the long run, V2.0 makes things simpler—at least for people comfortable with Object Oriented Programming—it creates two hurdles for an AutoHotkey user.
If you’ve written numerous scripts which you use on a regular basis, you will most likely need to update them to run under AutoHotkey V2.0. Second, if all your scripting experience relates to traditional AutoHotkey syntax, you will experience a slight learning curve—although not as steep as someone totally new to any form of programming.
On the plus side, it appears that both Hotstring and Hotkey formatting remains untouched only requiring modification of any embedded command code. Also, many commands, such as the Run command, appear unchanged in V2.0.
AutoHotkey V2.0 Progress
You will see hints to the progress of AutoHotkey V2.0 by watching the online documentation which evolves as progress in V2.0 advances. You can now view parallel V2.0 documentation by clicking the “v1” at the top of the Web page and clicking the “v2” icon. In many places, the word “legacy” replaces “traditional” indicating code receiving the ax in V2.0. For a more detailed description of V2.0 changes (what stays and what goes), see Version 2.0 Changes.
Right now in alpha testing, AutoHotkey, V2.0 beta testing—a more general release for final debuggin—comes next. Under beta test releases, anyone who downloads V2.0 hopefully reports bugs and mysterious events to the keepers of the code. The full release normally does not occur until the authors feel the program near bulletproof. While we can see progress on a regular basis (the latest alpha release occurred on January 6, 2018 —AutoHotkey Version 2.0-a083-97803ae), we don’t know when the first beta release might occur—much less the general release.
What Should I Do Now?
The short answer to the question, “What Should I Do Now?” is “Nothing—at least for right now.”
When available, you should probably implement the V1.1 alternatives to traditional commands, although, the general release of V2.0 does not appear imminent. (I could easily be wrong about this.) By using the newer methods provided in the most current version of AutoHotkey (e.g. identified with comments similar to “added with [v1.1.21+]”), it helps make you comfortable with the V2.0 syntax. Plus, when V2.0 does arrive, you’ll have less work when upgrading your scripts.
If, after AutoHotkey V2.0 does get released, you have no intention of upgrading, the current version (V1.1) likely will remain available for a long time—if not forever. While you can see that the current guardians of the software plan to make significant improvements to AutoHotkey, it’s highly unlikely that they want to cut off any legacy users. Even if supports drops for V1.1, the current (and earlier) versions of AutoHotkey have shown great stability for over a decade. Unless Windows becomes NOT Windows, AutoHotkey V1.1 likely continues viable and available for use for many years to come.
For Beginners—Don’t Wait
If you’re contemplating getting started with AutoHotkey, don’t let the uncertainty about V2.0 put you off. The only wrong decision would be waiting for any newer version. When it comes to learning to write scripts, any delay in starting the process forfeits valuable instructional time—not to mention the numerous benefits to mental agility. Even if you later switch to the newer script syntax and structure in V2.0, you’ll find the change much easier than starting from scratch. Plus, some of the most attractive features which provide instant results for newbies (e.g. Hotstrings and Hotkeys) remain intact.
The duality of the current version of AutoHotkey can cause some consternation, but the software works well—even when mixing old and new formats. Anything you learn now won’t be wasted. Over time, you’ll come to recognize the differences between traditional (legacy) commands and the newer expression/function formats while developing a deeper understanding of how AutoHotkey helps you simplify your Windows computing. Getting started now with AutoHotkey automatically prepares you for future changes—even if you eventually decide to stick with V1.1. In any case, the overall underlying philosophical and operational structure of AutoHotkey remains consistent and inviolate in V2.0.
How I Really Feel About It
While I applaud the efforts to make a better version of AutoHotkey, I really like the current version—even with all its oddities and foibles. No doubt when released, I will experiment with and write about V2.0. I may even publish a book about how to make the switch from V1.1 to V2.0. (I expect that people in the community will write AutoHotkey scripts easing the problem of converting legacy apps.) However, I do experience a human reluctance to give up on V1.1. I love it and may continue on with it until my dying days (or Windows dying days—whichever comes first).
Today’s AutoHotkey distribution demonstrates a reliability and soundness which doesn’t call for much improvement. For someone like me who revels in my multitude of Hotstrings (mostly AutoCorrection), a few Hotkeys, and a couple of simple apps, it offers everything I need. When the time comes, I’ll need to convince myself to make the change. I will certainly embark on the journey, but I wonder if it will surprise me in the same way as V1.1.
For example, I now know how to build superpower commands by embedding forced expressions in AutoHotkey commands. Force expressions using the % operator are destined to the dustbin of legacy code. Will version 2.0 do the same evaluation within its command functions? I suspect that it will—using functions within functions, but I’ll need to see how to do it.
The fact that V1.1 contains redundant methods for doing things doesn’t bother me but I do understand how much easier it would be if people only needed to learn one way to do things.
I don’t need to make a decision today and I have no idea when I might face it. However, when the time comes, I’ll wade in one toe at a time. I might love it and quickly immerse myself up to my neck. Yet, for now, I happily continue with my explorations of V1.1—ever mindful of the coming V2.0 developments. I find no reason for anyone to hesitate with the implementation of AutoHotkey on their Windows computer today. When the future comes, you (and I) can deal with it then.