AutoHotkey Community

I decided to write this thread for the benefit of newcomers to AutoHotkey. I hope that the more experienced users will be a little patient with this thread if they find its tone to be a little too elementary for them. It seems to me that if some of the experienced users want to give back to the AHK community, one excellent way would be to pick an introductory topic and write a post or thread to help new users with something that almost all of us have had to face at some point or another. I just hope that this thread will benefit new users and not be seen as just a pain in the neck. Please try to be patient and try to remember when you yourself were a newcomer and were having problems with these same kinds of elementary problems?

I hope that new AutoHotkey users will find this thread to be of interest. The topic is how best to handle a large number of hotkeys - specifically, how to organize them into files and how to ensure that you trigger the appropriate hotkeys when working on the appropriate tasks. I'm sure there are many different ways to handle these different configurations, and I hope the reason new users will find this beneficial, is because as they become more experienced with AHK, the number of hotkeys they create and try to manage tends to grow larger and larger. And, eventually, everyone has to face the fact that there are only a limited number of hotkeys available that can be put into a single file. So, eventually, we just had to somehow split our collections of hotkeys into multiple files. As that number grew, our collection of hotkeys likewise grew until they simply no longer could all fit into a single file.

I want to thank people like Majkinetor who contributed some fine suggestions and techniques on this topic and I'd very much like to encourage anyone else who wishes to get involved to please lend a hand. If you see something here that doesn't look right, by all means, please post a note to this thread and help us out.

So, just to get some definitions straight, let's define "activation key" to mean a combination of zero or more modifer keys (such as ALT, CTL, SHIFT & WIN) plus one regular key (such as one of the 26 letter keys or 10 number keys). There are usually four modifer keys (ALT, CTL, SHIFT & WIN) but different keyboards and different systems have different numbers and types of keys available. In addition, AHK enables you to define the left ALT key separately from the right ALT key and also enables you to make several other kinds of distinctions like that. AHK has many nice surprises like that available. Also, AHK uses the exclamation point "!" to stand for ALT, the "^" for CTL, the "+" for SHIFT and the "#" for WIN.

Another term we should define is "Script File" or "Hotkey Definition File" ("HDF"). Let's agree these both mean the same thing and they mean a text file that may contain zero or more hotkey definitions as well as zero or more AHK commands. A single HDF cannot be empty - at least it wouldn't be of any interest if it were. It must contain at least one command or at least one hotkey definition. However, it certainly can consist of a number of commands together with zero hotkeys or alternatively, it can consist of a number of hotkeys together with zero commands.

So, if you consider that you can use the 26 letters (A-Z) and the ten numbers (0-9) to activate your hotkeys, eventually, you will plumb run out of combinations. Let's say there are four modifier keys (ALT, CTL, SHIFT & WIN), then there are 16 combinations of modifier keys (ALT, CTL, SHI, WIN, ALT+CTL, ALT+SHI, ALT+WIN, CTL+SHI, CTL+WIN, SHI+WIN, CTL+SHI+WIN, ALT+SHI+WIN, ALT+CTL+WIN, ALT+CTL+SHI, ALT+CTL+SHI+WIN, NONE). So, this would mean there are a total of 16 * 36 or 576 possible activation keys available. Of course, this number is not very accurate. For one thing there are many more possible keys besides the 26 letters and 10 numbers. Given the 24 function keys, 10 number pad keys, plus all the punctuation, cursor, navigation keys, etc. there are probably closer to 100 heys than 36. But, on the other hand, many of those combinations are extremely awkward and painful to finger and so basically, no one would define all those combos as hotkey triggers because it would just be too awkward and painful to use them. But, the number of activation key sequences available is really not the important issue. Given that you can split up your hotkeys into several different files, and given that the same activation sequences can be used in multiple files, that means there are essentially an unlimited number of choices available. So, no one should ever have to work with hotkeys they feel are awkward or painful to use.

Originally, I thought the answer to this issue would be fairly simple and straightforward. But, I was wrong. It turns out that there are several ways to handle this problem - and depending on how you want to organize your hotkeys and how you decide to allocate various sets of hotkeys to match various sets of applications.

Originally, I split up my hotkeys into a few differnt Hotkey Files. I took all of the hotkeys I used when working with my word procesor and put them into a HDF named WORD_PRO.AHK. Then, I took all of the hotkeys I used when working with my editor and put them into a HDF named EDITOR.AHK.

There is nothing obviously wrong with this approach, and it may very well be a good way to work with hotkeys and if so, you will find the necessary commands used to load Hotkey Definition Files (aka Script Files) in the files presented here in this thread. But, just for your information, here is a sample hotkey that loads an HDF named EDITOR.AHK.



The directive (#singleinstance force) is required, and you should definitely look it up in the Help file to find out why.
The command (exitapp) is also required and you should likewise look up that command in the Help file to find out why.

However, you should know that this technique is somewhat flawed and it can become very awkward in certain cases. For example, if the nature of your work is such that you find yourself constantly "churning" back and forth, loading two different HDFs, then maybe it would be best for you to consider another kind of configuration.

For one thing, as Majkinetor explained, there is a very superior approach to manually loading and reloading a HDF every time you want to switch from one set of HKDs to another. It is possible to have AHK automatically get the correct hotkey from the correct file. So, you just press an activation key and depending on what app you are using, AHK can automatically access the correct HKD file and get the correct hotkey and fire that hotkey. You don't have to do a single thing besides pressing the activation key. That is just so beautiful!

Majkinetor explained how his (her?) configuration takes advantage of the #IfWinAcitve directive to automatically trigger hotkeys depending on which application is currently active. That means examining the "active window" and deciding to use one set of hotkeys that were created especially for that application. The real beauty of this technique is that it is no trouble at all to set it up and it happens automatically - in just an instant. You can have several sets of hotkeys available and depending on what you are currently doing (meaning which app is currently active) AHK will instantly assign the correct file to be used together with the application you are currently working on.

Doesn't that seem beautiful to you? It sure does seem beautiful to me. You just press the activation key and AHK instantly knows which hotkey to grab from which file. It reminds me of the OOP concept - late binding - where most anything is possible and it's only decided at the very last moment - which provides for a huge degree of flexibility. I am really impressed with the power behind this approach. Applause to Chris!

I should now explain the overview of my configuration. The background is that I have one main script file that contains most of my hotkeys. These are the hotkeys I use very frequently every day and in many different ways within several different applications. Let's call this main file MAIN.AHK. Then, I have another file that contains a number of editing hotkeys (thngs like changing the case of text from upper case to lower case and vice versa or maybe changing from lower case to capitalized case or sentence case - See the file EDIT_TOOLS.AHK for more details). I want these to be available whenever I'm using an editor or word processor. Lets call this file EDIT_TOOLS.AHK. This file contains hotkeys with the same activation keys as some of the hotkeys in MAIN.AHK. But they do different things and they do not get in each others' way. The way this is handled is the way Majkinetor explained how to do it. At the bottom of MAIN.AHK, I insert the following two lines:

#include EDITOR_HEADER.AHK
#include WORD_PROCESSOR_HEADER.AHK

Now, here is the file EDITOR_HEADER.AHK. It is an extremely tiny file:

#IfWinActive NoteTab Light ahk_class TEFO_FrmNotepad
#n::Msgbox EDITOR_HEADER.AHK
#include EDIT_TOOLS.AHK

And here is the file WORD_PROCESSOR_HEADER.AHK. It is also a very tiny file:

#IfWinActive Microsoft Word ahk_class OpusApp
#n::msgbox WORD_PROCESSOR_HEADER.AHK
#include EDIT_TOOLS.AHK


I got the names that I use in #IfWinActive (WinTitle & WinText) from the AutoHotkey SPY program. See the #IfWinActive directive in the Help file for more information. I use the activation key "#n" to let me know what script file is currently active - in case I forget or I'm not sure what script file is loaded, I just press #n and it shows me a message box with the name of the currently active HKD file. It's actually more complex than that - "#n" really indicates which script file will be triggered when I press a hotkey. The files can contain different hotkeys but with the same activation keys. For example, there might be a hotkey ALT+CTL+F2 in MAIN.AHK and a different hotkey - also with the activation key ALT+CTL+F2 in EDIT_TOOLS.AHK. But that won't cause any problems. If my editor or word processor is active, the hotkeys in EDIT_TOOLS.AHK will be fired. If any other app is active, the hotkeys in MAIN.AHK will be fired. They will not clash with each other.

Let me explain how this configuration would actually work in action. Suppose we have defined a hotkey ALT+SHIFT+L in the file EDIT_TOOLS.AHK that converts text to lower case. And, suppose we also have defined another hotkey ALT+SHIFT+L in the file MAIN.AHK that opens some unrelated document. Now, when I say that we have defined a hotkey ALT+SHIFT+L, what I mean to say is that we have defined a hotkey that is fired by the the activation sequence ALT+SHIFT+L. Some people would say that the name of this hotkey is ALT+SHIFT+L while others might say that ALT+SHIFT+L is just the activation sequence of the hotkey. To be honest, I'm not really clear as to what the name of the hotkey is. However, here is how these two different hotkeys would work:

When the user presses ALT+SHIFT+L, AHK will fire either one of the hotkeys in MAIN.AHK or EDIT_TOOLS.AHK. The way it decides is to check which window is the "active window". If the user is currently working with the Editor (meaning the "active window" belongs to the Editor), then AHK will fire the hotkey ALT+SHIFT+L in the file EDIT_TOOLS.AHK. Alternatively, if the user is currently working with any other application, (meaning the "active window" belongs to any app besides the Editor), then AHK will fire the hotkey ALT+SHIFT+L in the fie MAIN.AHK. This process is what I have called "the beauty" of this layout. All you do is press an activation key and AHK automatically selects the correct file and fires the correct hotkey in that file - and it all happens instantly. It's just beautiful.

Now, there is still another small problem worth mentioning. In my main hotkey file, I define some keys like the LeftSquareBracket and the RightSquareBracket to perform some functions. It's not important what those functions are, but the problem is that sometimes, I want to be able to type a LeftSquareBracket or RightSquareBracket and bypass the definitions in MAIN.AHK that I created for those keys. One solution is to load a "bare bones" hotkey file that only contains a few essential hotkeys. I load this for a second, type the brackets, and then reload my main file.

There are several other ways to solve this problem. But it's worth mentioning that it doesn't work under the current setup and I either need to be able to quickly load a "bare bones" hotkey definition file or I need to define some other activation keys (perhaps ALT+[ and ALT+]) to type the brackets.

For anyone interested in seeing the files in question, you may see them or download them from AutoHotkey.net:

http://www.autohotkey.net/~JDN/CONFIG/MAIN.AHK
http://www.autohotkey.net/~JDN/CONFIG/BARE_BONES.AHK
http://www.autohotkey.net/~JDN/CONFIG/EDIT_TOOLS.AHK
http://www.autohotkey.net/~JDN/CONFIG/EDITOR_HEADER.AHK
http://www.autohotkey.net/~JDN/CONFIG/W ... HEADER.AHK


MAIN.AHK - a large file of my every-day most commonly-used hotkeys

BARE_BONES.AHK - a small file that contains almost zero hotkeys - it just contains some hotkeys that load some of my other hotkey files - the purpose is just to be able to type characters just as if there were no hotkeys defined - just as if I was using a dumb typewriter.

EDIT_TOOLS.AHK - contains ten editing tools for doing things like converting the case of text, Indenting text, Unindenting text, Inserting text, Overtyping text, etc

EDITOR_HEADER.AHK - a header file that is included at the bottom of MAIN.AHK and contains an #IfWinActive directive to ensure that all the hotkeys in EDIT_TOOLS.AHK will only fire if the active window is my editor. This file contains an #INCLUDE directive to include the file EDIT_TOOLS.AHK.

WORD_PROCESSOR_HEADER.AHK - a header file that is included at the bottom of MAIN.AHK and contains an #IfWinActive directive to ensure that all the hotkeys in EDIT_TOOLS.AHK will only fire if the active window is my word processor. This file contains an #INCLUDE directive to include the file EDIT_TOOLS.AHK.

The file MAIN.AHK contains some hotkeys that load other Hotkey Definition Files - in particular the "bare bones" hotkey file. That "bare bones" file also contains the same hotkeys so that I can reload the main HKD file after I've finished typing using the "bare bones" file. Here are the relevent contents of MAIN.AHK:



Those same two hotkeys are also included in BARE_BONES.AHK so that I can load BARE_BONES.AHK at the stroke of the single hotkey ALT+CTL+2. Then I can do some typing as if I were using a dumb typewriter (because BARE_BONES.AHK contains almost no hotkeys). Then I can reload MAIN.AHK - also at at the stroke of the single hotkey ALT+CTL+3. It's not terribly elegant but it's certainly a very quick way to satisfy the problem. BARE_BONES.AHK contains exactly seven hotkeys - only the ones necessary to do a minimum amount of work and to reload the main hotkey file - MAIN.HKD.

You can monitor active windows and execute hotkeys automaticaly based on active application. Thats how I do it anyway and it seems much faster then above as everything is executing from single instance.

My setup is like this (example for 1 hotkey in 2 apps):


Shortcuts.ahk


EditPlus.ahk


FLStudio.ahk


You can easily extend this to support functions like redirecting hotkeys of currently active app to those of some other app , enable/desable etc...

_________________

That is very interesting. I need to take some time to think about it. But I think that is probably a much superior way to manage a large collection of hotkeys.

I only ever use about six apps at most. So, I could just target all of my hotkeys to the appropriate apps and the right one would automatically execute.

Most of my hotkeys deal with editing and word processing. I use two different editors and only one word processor. So, I would just target my editing hotkeys to operate only when an editor or word processor is active. That is an excellent approach.

Thank you very much.

This post has now become obsolete. Sorry.

I originally wrote this post to contain some conclusions I made about the process described in this thread. But, this post became pretty much obsolete and so I rewrote the info in the first post of the thread and hope that won't be too confusing to people who come to this thread looking for some help in dealing with large numbers of hotkeys.

Anone who has some suggestions or advice as to how to handle this topic or this thread is very welcome to participate. I would very much appreciate your opinions - either by writing a post to this thread, or by sending me a PM. Either would be fine, and I would thank you for your help.

Managing a large number of hotkeys! It is exactly the problem we faced at the beginning. We needed 100+ hotkey-macros to open websites/ files, select accounts/ fonts/ printers, start programs, type special characters and so on.

Actually we had 4 problems:

1. It was almost impossible to remember all of our hotkeys and even less possible to ask a part time employee to remember them.
2. It was frequent and very damaging to press the wrong hotkey which was activating the wrong macro.
3. It was time-consuming to find and modify a macro and/or replace a hotkey in our script file.
4. Some of the hotkeys that we were selecting for our macros were disabling useful existing hotkeys in Windows environment.

We solved everything with a customizable keyboard like the Enterpad. The graphic overlay on the Enterpad solved the problem of remembering and pressing the wrong hotkey. Actually, the way we built our AutoHotkey script file makes modifications a lot easier. Finally, our script file uses only one hotkey (F10) followed by a three digit number (001 to 120) to trigger 120 different macros. This means that we do not disable other predefined Windows hotkeys.

Our AutoHotkey script template, the Enterpad ready-to-print overlay and a tutorial are available free at www.cedeq.com/enterpad-p120/autohotkey-english.html

Enjoy!

_________________
epconfig
Enterpad Keyboard for AutoHotkey

the enterpad looks pretty cool. You need to whip up a gui to help users edit/create code.

You also should come out with different sizes of the enterpad. 120 seems like alot of hotkeys.

_________________

(Common Answers) - New Tutorials Forum - Humongous FAQ

+ That's an interesting idea how to make out of 1 hotkey N hotkeys using a number after the hotkey. For a 3 digit format we could multiplicate/increase our initial hotkey space from 1 to 1000 (000 .. 999), not bad.

If you would map certain numbers always to the same feature sets this would get useful, it would be easy to remember your hotkeys as they would have in each application sets the same functionality. e.g.

000 initialize
001 open
002 close
003 save
004 save as
005 undo

111 repeat
222 inverse repeat

... or any other much more intelligent mapping system, depending on the application area.

Having a midi keyboard with 5 octaves in front of me (5*12=60 keys) I wouldn't buy your Enterpad product. But it might be interesting for some secretaries who can do some extra work that their boss will buy an enterpad for them (after entering the secretary with their pad). I know not very funny.

automaticman,

The idea of doing 120 (virtual) hotkeys from 1 (true) hotkey came after we came across two problems using 120 different (true) hotkeys:

1. Some of the hotkeys that we were selecting for our macros were disabling useful existing hotkeys in Windows environment.
2. We had some problems when a hotkey had to trigger another hotkey.

Here is the script template I wrote to solve our problems:



Can it be easier?

We did not make tests with 1000 (virtual) hotkeys but I can say that AutoHotkey can easily manage 120 (virtual) hotkeys all day long.

_________________
epconfig
Enterpad Keyboard for AutoHotkey

Yes, I downloaded that code already from your site to test it. Have you any system/method/standard how to apply these "virtual hotkey numbers" to certain functions/features of applications?

The added value of enterpad is it's directness. You simply have a physical button, when pressed some action is triggered immediately. (No hotkeys, no mouse clicks, nothing else necessary.)

This means, as long as the automations are implemented 100% error free, the users of enterpad just have to know how to press the right button on the enterpad, nothing else.

The Enterpad is mostly used for business applications and they need more Hotkeys.

However, you can find smaller overlay keyboard like the “KB1700P-D-BG”. It’s probably easy to adapt them to AutoHotkey from the script we did for the Enterpad.

_________________
epconfig
Enterpad Keyboard for AutoHotkey

Can you give an example for a business application? What are common characteristics of business applications which differentiate them from non-business applications?

Several things differentiate business and non-business applications. Three of them are: Quantity, frequency and goals.

• Quantity: A home user can have 1 printer to print documents and a business user can have 10 printers and needs to select the right one before printing. A home user can have 1 signature email but business user can have many more to choose from.
  
• Frequency: A home user can have to print one document per day, business user several hundreds.
  
• Goals: Home use of a computer is mainly about entertainment. Business use is mainly about profit.

So, adding a layer of something to simplify something else is a calculated investment that business users like to do as opposite to home users who don’t worry about it.


Think about a user that has to type several canned answers for online technical support or a user that needs to access hundreds of department or account numbers in their accounting software.

Maybe you can’t understand where I’m getting at because I’m talking about very short macros like generating one number and it doesn’t make sense to remember one hotkey to generate one number. This is why people don’t think about using a macro software for simple tasks.

Everything is different with an Overlay keyboard because you don’t have to remember any hotkeys. Pressing the right labeled key will instantly generate the hotkey which will generate your number and so on for canned answers, special characters, menu/file/program/website access, etc.

_________________
epconfig
Enterpad Keyboard for AutoHotkey

If you could sell the Enterpad for less than
Total: 364.00 (Canadian $)
you could even market it as a musicians tool, like a midi controller, offering 120 buttons, which could be combined nicely with other midi poti-controller solutions. Electronic musicians would prefer maybe more a setup like 16 x 10 = 160 keys as many step sequencers use 16th notes for a bar/measure.
Maybe this idea is also worth considering, btw. how many Euro are 364 Canadian $?