I've been a huge fan of and user of AutoHotkey (AHK) for years, but I've got to admit (with a sense of betrayal) that I'm increasingly impressed with AutoIt. Last week I had an automation project I had to do and began to code it in AHK only to run into several major roadblocks. For the automation I needed to travel a thirdparty application's tree view UI to find a specific entry and click it. Later in the automation I had to do something similar with a list view control. I had expected to find easy mechanisms or code samples to do it in AHK. To my surprise I found relatively little, the built-in functions related to the GUI creation of those elements not the manipulation of already existing elements. And the little sample code/DLLs I found didn't seem recently updated and didn't work (with AutoHotkey_L). I accidentally stumbled across AutoIt threads on the topic and was pleased to discover it was quite easy with AutoIt, and their official support of those features in their standard include libraries. And thus began my journey into AutoIt.
Here are my impressions:
- The language syntax of AutoIt is more consistent than AHK, and mostly for that reason I liked it more. When I first started with AHK I found it really confusing that AHK supported multiple distinct paradigms (foo = bar and foo := "bar" as well as the whole Foo(Bar) and Foo, Bar (not to mention Foo Bar, the first comma being optional!?). I still find myself making quite a few typos/errors related to these situations... Forgetting what's a normal function and what's the other style function, putting a := when I meant a =. I'm sure the explanation for all this is historical, but the lingering embrace of all the styles simultaneously is odd (why can't Foo, Bar be called as Foo(Bar) so that people can write to the new paradigm)!! Oh, not to mention the hotkey hooking/specification stuff right there mixed in with regular code, which also confused me.
- The packaging of the setup/install of AutoIt is impressive, including the SciTe editor, example code, the extended library of functions, x86 and x64 compilers, obfuscator, build tool, auto updater, and more. I haven't installed AHK recently, so maybe AHK does just as complete an install. I was just pleased that in my testing/development I had to set this up on 4 computers and I couldn't have asked for an easier time of it.
- AutoIt has embeddable compiler and obfuscator directives! You can embed commands in the source that will trigger obfuscation, generation of both x86 and x64 binaries in one compilation run, you can include resources, set the EXE manifest-related data including administrator elevation, PE details, etc. Very nice!
- AutoIt Help files are almost useless when compared to their AHK counterparts. The index list and the keyword search functions seemed to miss a great deal that should be in their documentation, and it seems as though they do not include many (if not most) of their official support library functions in the help documentation. If you do find the page you need in their docs then everything is okay, they have good examples and references, but I'd swear 60-70% of the time I couldn't find what I needed and had to jump over to their forums or search with Google.
- The AHK community is absolutely amazing, and it would be hard to top them in terms of friendliness, helpfulness, knowledge, code-sharing, etc. I have only been an observer on the AutoIt boards as I looked for other people's solutions, and so perhaps my observation is meaningless, but I saw more grumpy unfriendliness towards newbies than I'd remembered seeing on the AHK boards. (I'm not saying the AutoIt community isn't great, too, it probably is, it just might be a little less tolerant of newbies and their poorly researched questions.)
- AutoHotKey automatically handles most UI interaction logic for you (via gGotoLabelName calling identifiers in the various GUI element creation functions) whereas AutoIt requires you to create your own windows message processing loop with switch/select message to handle every interaction to which you want to respond.
- As mentioned earlier there's a distribution-included obfuscator, which seems pretty good. The quasi-lack of one with AHK has been an annoyance of mine; AHK_L doesn't do the password thing any more, and I never had much luck with Hotkey-Camo or anything else.
- I was impressed with how quickly I was able to jump right into AutoIt using my AHK knowledge. I imagine it'd be harder coming the other way, because of the unusual multi-paradigm AHK language thing. Both languages are remarkably similar in their use, with many functions being identical in name and use. Example: Send, Foo in AHK is Send("Foo") in AutoIt. Within a few hours I was able to automate a relatively complicated and branched Windows dialog flow (related to driver installation, involving tree view navigation, list view navigation, support for different scenarios on different versions of Windows, etc.).
In no way am I concluding that AutoIt is better than AutoHotkey, nor can I conclude the opposite. My love of AutoHotkey isn't wavering, but I am glad AutoIt was there for a task which seemed like it would have been harder for me to do in AHK with the existing public code. So if you ever find yourself in a similar situation you needn't feel shy about trying out AutoIt.