autoIT versus 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
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?
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:
@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
WIN or LEARN.
Oh no, I'm settling for anything that works slower than the processor, so I'm learning machine code even as we speak.
If you want fastest learn C++ or C#.
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?
work your skill level towards post messange COM and register callbacks
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.
"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.
AHK does have arrays. Read up on objects. Example:
AHK does NOT have arrays
; 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%
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.
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.
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.
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?
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.
Good luck. When I view a piece of AutoIt code it hurts my eyes, I really don't like it all.