AutoHotkey Community

Hi folks,

I was in desperate need for some key remapping and stumbled across AutoHotkey and am loving it - straightforward and does the trick.

I couldn't escape the comparisons to AutoIt, so I took a look at it (http://www.hiddensoft.com/autoit3/index.php).

Unfortunately, AutoIt3 doesn't have much "promotional" info (though it does have online docs - but who wants to read reference materials to figure out what something can do?). At least, no enough to differentiate it from AHK (except maybe that stuff about .dlls that allow one to put hotkeys in apps).

Would someone here who is familiar with both AHK and AI3 mind contrasting them for me? Especially in terms of functionality offered. Just an overview is fine.

Thanks if you can help! - Mike

not a very good idea mate. Most that can be said is both are very good softwares, AU3 came to the scene first following AU2, AHK came later. I find AHK easy, but its an opinion and opinions differ.

_________________

I couldn't find hard proof, as the AU3's beta changelog doesn't include dates, but I'm pretty sure AU3 (AutoIt3) is older than AHK (AutoHotkey). I'll try to give a compare and contrast here, but you should know that I've never actually coded in AU3.

Well, AU3 and AHK are both based on AU2 (AutoIt2). However, it's interesting to note that while AHK provides backwards compatibility with AU2 (to an extent), AU3 does not. This is probably due to the first and most obvious difference between AU3 and AHK: syntax. Here is an example of a script written in AU3:



And here's one in AHK:



As you can see, it's quite different. AHK may be simpler for beginners or people who've never programmed; AU3 would be more familiar for programmers, especially those who work with Visual Basic.

Also, AU3 is (presumably) older, is more mature, and has a much larger community then AHK (almost ten times larger!). AU3 even has merchandise!

If you want to directly compare the AU3 functions vs. AHK commands, here's the pages:
AU3 Functions
AHK Commands

One notable difference is that AU3 has supported expressions (complex and regular) for a while; AHK just started supporting basic expressions yesterday. This doesn't mean much to the every-day beginner, though.

Now for the big whammy, which usually is the deciding factor for people trying to decide between AU3 and AHK; AU3 is made more for in-depth and general scripting, while AHK leans more towards user interaction, especially in the area of hotkeys (as the name implies). It's much easier to work with hotkeys (and other forms of user interaction) in AHK; in fact, AU3 doesn't even support as many hotkeys as AHK! I pulled this from the AU3 online documentation:



And last but not least, if you really can't decide, you could check out the editors supported by each. Understand that when I say "supported," I mean the ones that the installations include syntax files for, so the editor color-codes your syntax as you type it. If you don't know what that means, don't bother worrying about it.

AU3 Editors:
Scite
TextPad
Crimson Editor (free)
Source Edit (free)
UltraEdit

AHK Editors:
EditPlus
EmEditor
MED
PSPad
TextPad
AHK Editor (An AHK script, find on the forum)

So, if you already use one, it might be helpful to know if AHK or AU3 contains one.

And that's it! Well, actually, that's all I could find, really. If you want to look more into it yourself, here's some quick links to their respective pages:

AutoHotkey
AutoIt3

P.S. You posted this in the wrong sub-forum; it'd probably be more appropriate in General Chat, or possibly Support.

P.P.S. to Chris: In my search, I noticed this:



Does this mean we will be able to use AutoIt3 from within AutoHotkey? I don't yet know much about dll's, but I would definitely be motivated to learn if that's what this meant.

I think this post falls into a gray area. Although it might have fit a little better into one of those other categories, I think it's okay here too.

I believe the main intent of AutoItX3 is to provide automation capabilities -- such as sending keystrokes and mouse clicks -- in other languages that lack easy methods for doing such things. Therefore, although there would be little benefit to calling AutoItX3 from AutoHotkey, there could be a lot of benefit to calling it from your favorite programming language, such as VB or C++.

Thx Jonny. IMHO that description/statement was very helpfull.
Especially as it's from a user point of view.
Much appreciated.

B8)B:lol:

Probably already been touched on in the past, but I'm too lazy to do a forum search right now:

Any chance of an AutoHotkeyX?

Dll calling for AU3 is nice, but I personally think AHK is more full and better suited to the way I use my computer.

Thanks as always, jonny and Chris!


Right. And it looks like AI3 does not support mouse (or js) remapping. So the choice is clear, for me! That's about all I want!!

Not any time soon because it would probably be functionally identical to AutoItX3. This assumes my understanding of AutoItX3 is correct: that it's a collection of function calls such as MouseClick(), ControlSend(), etc. In other words, why reinvent the wheel?

I was actually thinking more of the functionality, that, as stated above, AU3 lacks, i.e. hotkeys, remapping, etc. But I guess that isn't as feasible to have for function calls, is it? Anyways, it'd really be nice to take AHK functionality with me into the programming world, if you catch my dirft. But I could easily settle for AU3 if not. It's very powerful, even without extensive hotkeys, hooks, and flashy thingies.

1st off they are both great automation/scripting languages. There are some things that AutoIT does better and there are some thing that AutoHotKey is better for. Comparing the two is a bit like comparing C++ to Pascal or VBscript to Jscrpt. AutoIT and AutoHotKey are both in the same "ball park", its mostly a matter of what you want to do and preferences.

Advantages of AutoIT:

Primarily, I see AutoITs advantage in its cutting edge implementation of additional features to its automation/scripting language. AutoIT can call DLLs, has a DLL form of itself as AutoItx, was first to implement the GUI between the two, probably will be first to implement COM, etc...

Secondly, I see AutoIT's advantage in all the USER scripts and TOOLS that they make. Look at AutoIT tools such as the adapted SciTe (which is free by the way), AutoScripWriter, AutoBuilder, FunctionPopup (in SciTe), Au3Recorder, etc... What you begin to understand that its not just about AutoIT's syntax, but about the 3rd party tools that are made for it. Luckily, for AutoHotKey though, this AutoIT advantage can never get that large because it is EASY to adapt AutoIT tools to AutoHotKey. Speaking of which Crimson Editor should have long ago been adapted/adopted for AutoHotKey (perhaps its time for me to do something about that so stay tuned)..

Overall, I see AutoIT rapidly becoming an automation/scripting language that can compete with WinBatch (including WebBatch), Visual Basic, VBScript, and Visual Basic for Applications (VBA) COMBINED.

Advantages of AutoHotKey:

Note- Contrary to some opinions that I have seen, I don't think of AutoHotKey as the "red head step-child of AutoIT3". Another thing, there is nothing wrong with "mutants" if their mutation gives them an ADVANTAGE or the borrowing ideas from other computer languages since it is done ALL the time.

Why did I type the above? Well, everything that you could possibly do has pretty much already been done or is being done by lower level (aka Assembly) or more powerful computer languages (aka Pascal, C++, etc...). How does AutoIT compare in power to C++, Assembly, or Pascal? In terms of "PURE POWER", it CAN'T. But in terms of "EASE OF USE", it can and it can be BETTER for many users that don't want to deal with the complexity, difficult syntax, etc... of other computer languages.

Basically an automation/scripting language such as AutoIT is making "SHORT CUTS" to do doing various tasks that would be HARD in OTHER computer languages. On that "note" this is where AutoHotKey can make its "entrance".

AutoHotKey:

1. Easier to use. When I compare the syntax of AutoHotKey to AutoIT, I have noticed that overall (in my opinion) that AutoHotKey is easier to use, but nearly as powerful. That's a huge plus for NEWBIEs and PART-time programmers. In fact, if the explanations in the AutoHotKey Help were a little more clear than this point would be even more obvious on how much easier it is to use AutoHotKey. Overall AutoHotKey has embraced the "Ease of Use" concept and this alone gives any automation/scripting language an advantage OVER traditional computer languages such as C++, Pascal, or even Visual Basic.

One thing that I have noticed is that when it comes to scripting languages there seems to be 4 types:

. Power Users- Often had a problem that could not be solved by no other means but to use automation/scripting or accidentally discovered that scripting could have solved a previous and could be used to increase control over computer.

. Power Users that are transitioning to being Part-time Programmers- After repeatedly having to solve various computer problems with automation/scripting or likes the idea of solving computer problems with scripting, has decided to learn more about scripting and/or programming.

. Part-time Programmers transitioning to becoming experienced Programmers- Confident enough to use scripting or programming to solve computer problems. Will often experiment with ways to use scripting or programming for FUN or for some unknown FUTURE problem based on experience with past problems.

. Experienced to Expert Programmers- Studied to become a programmer, actively employed as a programmer, or wish to become a programmer. Throughly knowledgeable about a particular programming language and knowledge can often extend to several computer languages.

I mentioned the above, because when it comes to "Ease of Use" a significant issue often occurs. Advanced Programmers will use a scripting language for "convenience", fun, experimentation, etc... and often have 1 other or several other ways beside using a single scripting language (like also knowing C++, VB, or Pascal) to solve computer problems with their knowledge of a programming language(s). On the other hand Power Users and Part-time Programmers do NOT have this option because they don't know enough, only know 1 scripting language (like WinBatch, AutoIT, VBScript), they have NO intention on becoming professional programmers/advanced programmers, or want the simplest method to solve an issue. Many programming languages that attempted to imply they were "simple" are often viewed as NOT being so to regular Users, Power Users, or even Part-time Programmers. A good example is Java or Jscrpt. Hell, there is even an argument that you could learn Assembly, aka MASM, (about as low level as you can go to machine code) equally as fast as C++.

Many Power Users and Part-time programmers really want "truly" easy to use, not "simple" in comparison to learning and programming directly in binary code.

2. Implementation advantage. What does that mean? Well, because AutoIT is "cutting edge", AutoHotKey programmers and development team (aka Chris, Rajat, and anybody else that wants to join the gang) can evaluate what newly implemented concepts worked well or didn't. Subsequently, AutoHotKey programmers and development team can then modify those concepts, the syntax used, or improve upon the ideas displayed.

Also this does not mean that AutoHotKey people have to wait either, since the automation/scripting language is free to implement its own concepts that would be advantageous, easier to use than in a traditional programming language, or easier for computer power users to learn.

Damn, timed out. The above was posted by AHKnow.

I also want to mention that I would still like to see more advanced features for AutoHotKey be developed, but to keep the "Ease of Use" concept in mind. A nice direction for AutoHotKey would be parhaps COM/OLE (for playing more with Word, Excel, MS Office...) since that would "complete it" as an automation language.

Anything new in AutoHotKey, should perhaps be easier than C++, Visual Basic, etc... I think that's the key. Afterall if we want to do it the "hard way" than why not just learn Assembly or machine code.

I do seem to remember that a finished release of AutoHotKey was out and ready for use before AutoIT3 was offically released. I think the issue was that their were many AutoIT2 users that wanted AutoIT to continue and AutoIT3's release kept being pushed back or delayed. The issue would then be if AutoIT3 had a beta out before AutoHotKey, but even it their was, it was still an early beta or perhaps even an alpha.

AutoItX3 already has COM:



Too tired to fully answer your post now; someone else will probably get to it before I can. I'm off for tonight.

That is incorrect. AutoITX3 can be used AS a COM Object. Right now, I think it can only be used as a DLL. That means the programming language calling it, if they have the AutoITX3 COM interface for the also AutoITX3 DLL ready, must have COM/OLE commands in that language.

AutoIT3 can NOT perform COM/OLE, nor does it have any syntax in it automation/scripting language to do so. There are no commands like CreateOleObject and GetActiveOleObject in AutoIT3.

Therefore, I'm hoping that maybe AutoHotKey can go into this direction.

Example from Pascal Script used in Autorun Pascal Builder http://www.muralexandru.as.ro/ (it can call DLLs and do COM/OLE by the way).

Quote "Pascal script can access COM (also known as OLE or ActiveX) methods and properties via the COM Automation objects support. This allows you to access for example standard Windows COM servers, custom COM servers, Visual Basic ActiveX DLLs and .NET assemblies via COM Interop.

There are two support functions related to creating COM Automation objects: CreateOleObject and GetActiveOleObject.

Use CreateOleObject to create a new COM object with the specified class name. This function returns a variable of type Variant if successful and throws an exception otherwise. The returned value can then be used to access the methods and properties of the COM object. The access is done via 'late binding' which means it is not checked whether the methods or properties you're trying to access actually exist until the Autorun actually needs to at run time.

Use GetActiveOleObject to connect to an existing COM object with the specified class name. This function returns a variable of type Variant if successful and throws an exception otherwise. In case of some programs, this can be used to detect whether the program is running or not."

I, for one, think this deviates from the de facto maxim for Chris' decisions - "10% of site visitors". More advanced users like Chris and Rajat might have a clue what you're talking about, but I don't, and I'm assuming that a large percentage, if not a majority, of the people reading this don't have a clue either, or if they do, they don't care about it in regard to AutoHotkey. AutoHotkey has always been easy to learn and pick up, even for people with no programming skills whatsoever (like yours truly).

Now, I only have a vague idea of what ActiveX even is, so I'm not going to argue schematics or usefulness; I'm just saying that it would only be useful to a small percentage of AHK users, and it would probably take a tremendous amount of effort on Chris' part to implement it. Heck, it's open source, though, you could take it and implement COM controls if you wanted. I'm sure Chris would be delighted with the idea.