processing limitations or reasons not to use ahk for larger programs? Topic is solved

Get help with using AutoHotkey and its commands and hotkeys

processing limitations or reasons not to use ahk for larger programs?  Topic is solved

17 May 2018, 08:46

I'm just wondering if there are any practical limitations using AutoHotKey to write larger programs?

It's just that I've been writing a program for a ... ahh.. well I just looked into it and i've got related files over 5 years old :problem:

So as you can imagine with continual development what started as a simple script is something that I would consider legitimate software. For the initial purposes of the 'script', AHK was ideally suited for it, taking hotkey imputs and launching programs. However, now I intend on feeding datasets through it. AHK had no problem creating the first test dataset, but my intent is to add weight to these stored variables based on the user's behaviour when using the software. ie the user ends tasks labelled 'red', send less and less tasks labelled 'red' the more the user kills them. the first test database it created has 8000 keys so far and it's nowhere near complete and I haven't even started assigning them weight.

Can I keep using AHK, or am I going to have to create a module in another language and feed my base program data, or rewrite the entire thing? I'm thinking if there is any time to do this it should really be now. I'm just concerned at the huge task to rewrite 5 years of writing endless lines of nonsense then repacking it into loops I can barely follow.

If I should rewrite it or write new modules, what should I use? In technical terms there's nothing in the software beyond launching, tracking and managing software windows and basic key input and output. everything it manages is well behaved, unlike a few games i've use AHK to script that need a range of specific conditions written into the script to interpret the i/o. everything else about how it calculates how it behaves and basic gui prompts are a simple enough.

I was just a bit concerned as Microsoft Excel often very repeatedly tell me to go f myself. It loves to crash at save time when I'm getting a bit extreme with my vb and referencing. Its just that ahk has never hit me with some weird bugs like a lot of vb based software if you don't have the correct reference files etc, it's never given me any headache beyond just getting the code right. I recently wrote something cool in bash to wrap some logic around some curl commands to fully automate downloading files upon availability, sanitizing raw names to reference/describe/upload elsewhere. But my god, the errors that made absolutely no sense even after resolving them and the nonsensical soup of commands each with their own unique syntax.

to all the developers of ahk, thankyou very much, with the exception of microsoft excel i've enjoyed using it more than any other software :) although this post has made me realise that maybe I use excel like someone trying to paint a wall with a hammer. :geek: :facepalm: :dance:
Posts: 519
Joined: 11 Jan 2017, 17:59

Re: processing limitations or reasons not to use ahk for larger programs?

17 May 2018, 09:47

having read through your entire post, i still have no idea what the actual question really is, you go off on so many tangents

can you use ahk to develop large projects? yes. should you? it depends. its a tradeoff between whipping up something quick and going for something else that is more robust, a tradeoff you have to make the judgement call on, yourself
User avatar
Posts: 4290
Joined: 19 Dec 2016, 01:58
Location: UK

Re: processing limitations or reasons not to use ahk for larger programs?

18 May 2018, 07:43

- AFAIK I have never had a problem with AutoHotkey that has necessitated using a different programming language instead.
- Thus, the only potential problem could be speed. But this is a general programming problem, not a specific AutoHotkey problem.
- Using VarSetCapacity with variables or SetCapacity with objects could help with making writing to variables/arrays faster.
- Adding keys to an array in alphabetical order can be much faster than in a random order.
- A rare situation: for something that needs to be super fast e.g. Gdip_ImageSearch, it can be a good idea to write machine code, e.g. in C++ and then compiled, and thus create a machine code function.
- [EDIT:] You can set the process priority.
- [EDIT:] Perhaps multithreading and therefore AutoHotkey_H could be useful.
Last edited by jeeswg on 18 May 2018, 08:18, edited 1 time in total.
Posts: 116
Joined: 05 May 2018, 12:23

Re: processing limitations or reasons not to use ahk for larger programs?

18 May 2018, 08:08

Only issue is if you want to create software that you sell and would like to make it very difficult to reverse engineer. AHK even if mpress is used, it takes less than a minute or so to get the code. Other than that, I have seen personal projects that were very big that run smoothly for years that were built using AHK.
User avatar
Posts: 60
Joined: 27 Oct 2017, 14:30
Facebook: They have no decency!
Google: They have no decency!
GitHub: Ixiko
Location: Somwhere between Mars and Earth

Re: processing limitations or reasons not to use ahk for larger programs?

18 May 2018, 11:26

Yes i think there's no limitation for large projects. My project grows up and my decision to take Autohotkey was to have a language that is easy to understand for my collegues. Theres allways something wrong, changes are made to the original software, so its impossible to have a good service for software written in C. Best for me to do it in Autohotkey. For now I break the 10.000 lines zone and this is only the beginning! I have reorganized the script layout for not to loose my way, but I think this is normal after launching a rocket without making plans before. For me it was the best decision.

Return to “Ask For Help”

Who is online

Users browsing this forum: AHKd00b, chef423, llinfeng, mynameisjohn, osuki9x and 30 guests