Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate

autoIT versus autohotkey


  • Please log in to reply
291 replies to this topic
JohnnyGui
  • Guests
  • Last active:
  • Joined: --
I've used both and would have to say it's all about personal preference. I find AutoHotKey to be simpler and easier to use than AutoIT3. I haven't really found myself able to do anything in either of them that I couldn't do in the other. I think they are pretty much equally powerful. My advice would be to try them both and see which one you like better.

B-2Admirer
  • Members
  • 7 posts
  • Last active: Mar 06 2012 11:34 AM
  • Joined: 14 Oct 2011
OK, how about some friendly (but above all honest) advice? I've been using AutoHotkey for a long time, grew more or less dissatisfied with it, tried AutoHotkey_L 1.0.95.0 and it appeared even worse (because it was slower for my tasks and some AutoHotkey scripts didn't work), so I stuck with AutoHotkey.

Since I'm probably going to write quite a few scripts in the near future, I'm wondering whether I should stick with AutoHotkey, go to AutoHotkey_L or forget about AutoHotkey_Whatever alltogether, grind my teeth and move to AutoIt, learning a different script language in the process (which means sacrificing a lot of precious time).

Now, I do realize that the answer to the question "which one is better" may depend on "what's the task", so here's what I want to do.

1) Parsing text files (or rather, files that contain text). Using AutoHotkey for this is annoying because
a) RegEx operations can be very slow and sometimes performed incorrectly, for instance when the size of the match is too large for AutoHotkey to hadle
B) for some unfathomable reason AutoHotkey doesn't work with files that contain binary zeroes, which some of the files I parse do, necessitating the use of third-party tools.

2) Automating GUI applications. AutoHotkey is no piece of cake here either, because control-specific commands often doesn't produce the desired results, for instance sending keystroke of "Shift" and "Alt" keys to a certain control interferes with the whole system, sometimes I wasn't able to get an application to receive a ControlClick or get the text from an application.

How well does AutoIt handle the things I mentioned?

Mickers
  • Members
  • 1239 posts
  • Last active: Sep 25 2015 03:03 PM
  • Joined: 11 Oct 2010
If you want fastest learn C++ or C#. I don't know anything about Auto-It but i doubt the speed gain would be worth the time and effort you would have to put into the different syntax.

The latest version of ahk_l boosted the speed of regex you may want to check it out at least before you do anything drastic. :wink:

tank
  • Administrators
  • 4345 posts
  • AutoHotkey Foundation
  • Last active: May 02 2019 09:16 PM
  • Joined: 21 Dec 2007
I am going to get boo'd but I'm tank so it comes with the territory

@B-2Admirer In general Autoit comes with more extensive built in libraries and better configured IDE from an overall completeness standpoint. It has much more robust set of commands built in. While these things are true it is also true that due to memory management practices of autoit most commands perform a bit slower. It is also true that everything you can do with it you can find a way to do with AHK_L.

Almost all performance issues with AHK(most languages any way) are the result of poor programing practices. I am not trying to start anything. I often write large scripts that are clunky and crash then spend weeks or months tweaking and modifying to enhance speed and stability. I have several always running scripts thousands of lines long with no performance issues. These scripts run on hundreds of computers


Code optimizing is something of an art and less a science tho and it takes time and experience. In general test as little as possible for your algorythm to work. Dont work entirely within global space. Do as little as possible with the mouse and or send commands. I havent found anything yet that i cant work past needing those. Avoid window commands when possible. work your skill level towards post messange COM and register callbacks. Do not compile scripts in my experience it is never as good an idea as it seems like. oh and not a performance reason but always work in expression mode for ifs and variable assignment
Never lose.
WIN or LEARN.

B-2Admirer
  • Members
  • 7 posts
  • Last active: Mar 06 2012 11:34 AM
  • Joined: 14 Oct 2011

If you want fastest learn C++ or C#.

Oh no, I'm settling for anything that works slower than the processor, so I'm learning machine code even as we speak.

work your skill level towards post messange COM and register callbacks

OK, let's I have an application I want to automate. How am supposed to know which COM object do what I need, or even if the application is a COM object?

Mickers
  • Members
  • 1239 posts
  • Last active: Sep 25 2015 03:03 PM
  • Joined: 11 Oct 2010
The MSDN

B-2Admirer
  • Members
  • 7 posts
  • Last active: Mar 06 2012 11:34 AM
  • Joined: 14 Oct 2011
Since I have received very little useful information here, I decided to check the relevant functions of AutoIt myself. Having done that I can only mourn that I found AutoHotkey first and wasted so much time with it. AutoIt is certainly better suited for data parsing as it can handle binary zeroes no problem and while its regex implementation is not bug-free (some patterns don't work as they should), so is the case with AutoHotkey, althought I have to admit that for now finding the right pattern in AutoIt is more of a problem than in AutoHotkey. The fact that Regular Expressions in AutoIt are not fully documented, much less so than in AutoHotkey, even some perfectly working sequences like \R or \K are not even mentioned in AutoIt documentation, is not helpful either.

Regarding automating GUI applications, control-related commands in AutoIt appear to work exactly like their AutoHotkey counterparts, so for this task AutoIt is probably neither better nor worse.

What really sets AutoIt miles apart from AutoHotkey, though, is its strict and neat syntax, which seems a joy to behold after the syntax of AutoHotkey, which can only be described as ugly and haphazard.

So what I decided is this: I will continue use AutoHotkey for existing scripts, but whenever possible shall write thew ones for AutoIt, while slowly porting the most frequently used scripts to AutoIt as well.

  • Guests
  • Last active:
  • Joined: --

What really sets AutoIt miles apart from AutoHotkey, though, is its strict and neat syntax

Good luck. When I view a piece of AutoIt code it hurts my eyes, I really don't like it all. To each their own.

guest10
  • Guests
  • Last active:
  • Joined: --
Frosty Jack wrote:

"Not to mention, that AHK's array / object implementation, etc. is way better...okay, I did have to mention it, since it's just one more point that shows, why AHK's better."

I'm reading these threads since I must write scripts, and hence decide if it'll be AHK or AI, first posts within the AI forum have been as desastrous as it is in length described here, the a**has*** factor in the AI forum being about 85 (not 100 though) p.c.

My first reaction AFTER (my humble) comparing was to go to AI then, since I thought that AHK does NOT have arrays, and I'm in absolute need of arrays for the work I need to do.

So could you explain to me what Frosty Jack means when he says that in AHK, arrays are even better implemented than in AI?

The array thing is decicive for my choice.

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007

AHK does NOT have arrays

AHK does have arrays. Read up on objects. Example:
; Create an array
array := [10, 20, 30, 40]
; You can flexibly add new items to the array:
array.Insert(50)
; ...or even use text as keys, something which is not possible in AutoIt3 AFAIK:
array["hello"] := "hello, world!"
; Display all the elements of the array
for key,value in array
    MsgBox array[%key%] = %value%


ahk2539
  • Guests
  • Last active:
  • Joined: --
Thank you very much for this answer, fincs. You see, the web is full of assertions that AHK has NO arrays, even in 2008 and 2009, and as far as I have got it, some users have written pseudo-array functions that can be integrated into AHK; idem for AHK_L where there is an array function built up by third party, and the "definitive" AHK array integration seems to be the big function "AHKA" or "AHKArray", also a third-party add-on.

Within AHK itself, there seem to be simili-arrays = strings, and if you have very big "arrays", let's say 100 dimensions and 10k rows, a lot of single strings are then in the memory of your computer, instead of one big package; of course, I ask myself about the possible memory stability of such a system (6-digit different memory addresses, etc. - crashes? false attributions?), let alone possible performance problems.

To go back to my question: How can somebody think such an extraneous array system can be BETTER than normal array capabilities of a given script language?

I'm not posting in order to flame AHK, I'm posting in order to better understand, which, up to now, has not been the case.

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007

some users have written pseudo-array functions that can be integrated into AHK; idem for AHK_L where there is an array function built up by third party, and the "definitive" AHK array integration seems to be the big function "AHKA" or "AHKArray", also a third-party add-on.

Wrong.

AutoHotkey_L is now the de-facto official build, and its array/object support is not based on pseudo-arrays, but on a new "datatype" that can be contained by variables. This is the "definitive" array solution.

hackit
  • Guests
  • Last active:
  • Joined: --
Is there somebody else who can give his detailed opinion, in more than 5 words?

I've just seen THIS thread, 1 year old:

https://ahknet.autoh... ... bjects.htm

Up to now, I did NOT find anything positive about AHK arrays, except for the big and the simple third-party amendmends, within their respective descriptions (but nothing about reliability, except for warnings on possible problems), and the "L" version now being the official build? Do the developers see this in the same way?

Can anyone give some background? Some positive experience?

fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
Fincs is a developer and what he said is true. AHK_L is the standard AutoHotkey distribution since Chris is not working on it anymore. There are no real problems per se, just some incompatibilities to the last non-L version of AHK that don't matter for any new scripts. The array/object support is somewhat mature and usable for bigger projects but there might still be some changes in later versions. There is also support for class-syntax.

B-2Admirer
  • Members
  • 7 posts
  • Last active: Mar 06 2012 11:34 AM
  • Joined: 14 Oct 2011

Good luck. When I view a piece of AutoIt code it hurts my eyes, I really don't like it all.

Well, I think I know what you mean :wink: All those quotes, parenthesis and dollar signs may seem unsavory if you aren't used to them, but hey, this is what makes a script logical. In AutoIt there is no need to escape anything but quotes (by doubling them). In AutoHotkey you may have to escape commas, percents, accents, semicolons, spaces... and quotes, which is bound to lead to wasting time on debugging a seemingly sound script.