That’s how the email I got last week from Philip started
He sent me two AutoHotkey scripts he wrote.
In one he used a single subroutine and in the other he did a call to a copied function.
That was about it, seemed simple enough
He was trying to change his scripts to make them do more
So he tried looking in the docs and searching on the Autohotkey.com forum
But as he said to me: “I do not even know what things are called so how can I know where to begin looking.”
He felt confused, It made sense to me!
I asked him about the current subroutine in his script, he was unsure what I was referring to, Subroutine!?
I don’t remember when I started calling parts of a script for subroutines
I can’t even point you to a reference about how you create a subroutine in Autohotkey.
Not to mention when you have never done any coding before.
How are you to even know the terminology.
I feel, I understand Philip’s confusion, as I also started without knowing any of the terminology, so I’ll use a little time to talk about what I have come to know about and call some of the different scripting elements today.
So, I’ll talk about commands and subroutines
Little about functions and the object
And shortly touch on classes.
Knowing when to use each, in addition to the best way to use each
Is a fundamental aspect of learning more about how you can use AutoHotkey.
Of course if you ever read Code: The Hidden Language of Computer Hardware and Software then the things I’m going over in this post may seem a bit overly simplified.
I see the command as the basic building block in Autohotkey,
One of the simplest ways you can use AutoHotkey, is by using a single built-in command
These take up one line, starting with the name of the command followed by that commands options also called parameters
All AutoHotkey commands and their parameters can be found in the online and offline help file
A subroutine is in a way also a basic unit in Autohotkey.
I like to think of Subroutines in a couple of ways.
One way is a simple subroutine.
This is basically a series of Autohotkey commands that are interpreted sequentially.
The script starts at the top and works its way down, line-by-line, until it reaches the end of the subroutine or script.
Usually, I keep these short (less than 50 lines), you’re able to make them even longer (100 or 20000).
I write these sorts of subroutines as a kind of quick one-off creations.
They do nothing I could not have typed into a larger, always running script
Sometimes when it’s a bit longer than a one-liner
Like something that makes a common task easier
Then I do tend to keep it
Maybe putting the routine into its own named script file or overall script used for similar things.
Subroutines like this:
Most of the time don’t take advantage of any advanced scripting features of Autohotkey (no OnMessage, COM, or Classes).
When the script grows beyond the level of the subroutine, I begin to group related commands into a function.
A well-designed function has one way in and one way out, and it performs a single activity.
At least, that is the way I like to write and design my functions.
Also a well-designed function also returns something meaningful.
By having one way out
And by performing a single activity
It makes it easy to troubleshoot the function.
It also makes it easy to reuse the function in another script, or to place it into a class later.
A script can contain one function or more functions.
When my script begins to grow in length and complexity
I try to keep moving related commands into functions.
Trying to make functions reusable means that you need to add a level of abstraction to a function
This sometimes requires a bit of thought.
Where as a straight-line, quick subroutine may have hard-coded paths, and string literals in it
You may need to abstract all of these literal values into variables, to make them usable when you move them into a function.
Making it a habit early, to begin thinking about where those variables will be used:
Either only in the function, or in the script, or even outside the script, is a great learning step.
A very basic way to look at an object when first starting to use object in AutoHotkey is that it’s a variable that holds other variable names (keys) and values (values)
An example of two simple ways to view or use objects in Autohotkey are the array and the associative array
In arrays each key (variable name) is numeric, and made automatically by the script
In associative array each key (variable name) is a string, and named manually by the writer.
Originally in AutoHotkey, there was no objects or arrays only lots of variables and functions, both were only accessible by using their name.
However, objects added a brand new way of accessing both variables and functions.
Giving access to even more things like Extensible associative arrays, Methods, Function References, COM interfaces, Classes and more…
The Class a super global object, with its own syntax, that can simplify that use of objects.
As the Class is in the global space of a script aka callable from anywhere in the script it is the logical place to store a collection of related Autohotkey objects and functions.
I can include a class in my script, and then I automatically have access to all the functions stored in the class.
As an example, I created a class that contained a series of functions that were designed to work with website accounts.
I had functions to create a new website user, add the website user to a group on the site, maybe change the account’s password, and so on.
Because these tasks were all related to things I would do to a single websites accounts
I stored them all in a single Class.
But I did not write all of these functions at one time
No I added to the class over time as the need came up.
Each time I modified an object’s values or made a new function, I extended the class with a new part.
Making the class a great resource, giving easy access to an encapsulated array of functionally.
That was a very short rundown that may help with your understanding of AutoHotkey scripting terminology, if you’d like to read more about programming concepts then John C. Mitchell’s book Concepts in Programming Languages is a good read.
Autohotkey Scripting Thoughts will continue next week, where I will talk about Best Practices when scripting with Autohotkey.
See you next time. Until then