While You Can Use an External File to Save Your Script Defaults, You Can Also Call-on the Windows Registry to Store App Settings
In most cases, I’ve used a separate file (text or INI) to save settings. While this works well, it requires the creation and tracking of that independent file. For the script to read the settings, it must know where to locate that file. But, if you want to save script settings without the baggage of that extra file, then consider using your Windows Registry.
You’ll find a few advantages to maintaining your script settings in the Windows Registry:
Unlike a separate settings file, you don’t need to keep track of the Windows Registry’s location—it never moves. Regardless of where you locate your AutoHotkey script on your computer, you will always find its settings in the exact same place.
You won’t accidentally lose your settings by manually deleting what may seem like an extra file in Windows File Explorer.
Your settings remain semi-hidden from public view in a semi-permanent form.
This approach to storing your script defaults deep inside the recesses of Windows adds an air of mystery to your apps—especially if you compile them into EXE files. Continue reading →
If You Run a Number of AutoHotkey Scripts Simultaneously, Distinguish Each Icon in the Windows System Tray with These Menu Commands
At times, I’ve found that I have six or more AutoHotkey scripts running at the same time. Each one adds the little green icon with an embedded “H” to the Windows System Tray. This gets confusing. I can only tell them apart by hovering the mouse cursor over an icon and reading the script name in the Tooltip pop-up message. Sometimes the Tooltip alone doesn’t do an adequate job. Continue reading →
Rather Than Using Hotkey Combinations, a Simple Click of the Icon in the Windows System Tray Launches Your App
One of the features I added to the InstantHotkeyArrays.ahk script turns the Windows System Tray AutoHotkey into a one-click button for launching new Instant Hotkeys. The new hot-button made from an existing icon works out well—especially since I can never remember the Hotkey combination for creating a new Instant Hotkey. Continue reading →
This AutoHotkey GUI (Graphical User Interface) Trick Builds New GUIs (Graphical User Interfaces) On-the-Fly and in the Same Script without Conflicts
I originally wrote the InstantHotkey.ahk script as a practical demonstration of how to use the Hotkey GUI control. The script’s major downside involves the need to run a new instance of the app for each new Hotkey combination/insertion text pair. Adding the #SingleInstance Off directive solved the problem of loading the same script multiple times, but the System Tray clogged with icons after initiating a number of Instant Hotkeys simultaneously. (I couldn’t just eliminate the System Tray icons (#NoTrayIcon or Menu, Tray, NoIcon) because I could quickly lose track of the various Hotkeys. Plus, eliminating tray icons presents other dangers.)
I combined the script with my master AutoHotkey script by including a Hotkey and the Run command (^!h::Run, InstantHotkey.exe). This avoided the problem of multiple conflicting GUIs in the same script—although it did nothing about the System Tray icon overload.
My recent work inspired me to solve the problem by uniquely naming the GUIs. In the course of writing the new script, I added a number of other useful techniques which I plan to cover in future blogs. Stayed tuned! You might find a few of them quite helpful. Continue reading →
Auto-Fill Windows Program Data Fields Using RegEx—Plus, Alternative for Pop-up Messages
While the Coloretta Viva script copies pixel colors, transferring codes to Windows Paint gets awkward. This AutoHotkey data filling technique for multiple fields works in any Windows program. Plus, we look at another method for popping up user messages.
Rather Than Increasing the Length of a System Tray Menu, Add Submenus—Plus, How to Use Menu Names (A_ThisMenu) for Conditional Actions
When I decided to add two more recipes to the Jack Stuffed Cheeseburger script, I ran into the problem of adding too many items (one for each step in each recipe) to the System Tray right-click menu. In the original, Cheeseburger.ahk script, I only included four steps in the menu (Ingredients, Prepare, Cook, and Serve). However, after inserting the Animal-Style Cheeseburger and the Jack Stuffed Cheeseburger (Animal Style) into the script, the number of recipe increments jumped from four to 18—plus an additional Print Recipe option for each burger. Also, since many of the steps use the same (or similar names), I needed a method for identifying each step with the proper recipe. When increasing the number of AutoHotkey menu options, cumbersome lists of items commonly crop up. You can fix these bloated menus by using submenus. Continue reading →
Note: I changed the CheeseburgerRecipe.ahk script in a number of ways—a few of which I plan to discuss in future AutoHotkey Tips. For now, I confine myself to highlighting the use of the GoTo command. For specific changes, see the comments at the top of the CheeseburgerRecipe.ahk script.
Adding Options to the Cheeseburger Recipe
I found another recipe at FoodNetwork.com which replicates the In-N-Out Animal-Style Cheeseburger recipe. Copying the same AutoHotkey techniques I used for the Jack Stuffed Cheeseburger, I added the new steps for this recipe to the script. Since the System Tray menu grew too crowded, I implemented submenus for each recipe. (See image below.)
The primary differences between the Jack Stuffed Cheeseburger and the Animal-Style Cheeseburger include caramelizing onions, mixing a special sauce, burgers with no embedded cheese, preparation of the buns, and frying the burgers with mustard. While more involved than the first recipe, the new recipe might satisfy the “Animal” in anyone. But, what if you wanted a Jack Stuffed Cheeseburger Animal Style?
You could write an entirely new recipe for a Jack Stuffed Cheeseburger Animal Style but that would include a great deal of redundancy. By using the AutoHotkey GoTo command, we combine the redundant steps of the two recipes to create a third variation.
For the new Jack Stuffed Animal Style Cheeseburger, the recipe starts at the Label point Stuffed_Animal_Ingredients: which includes the ingredients for the Animal Style Cheeseburger plus the added Jack cheese (for stuffing) and varied meat and cheese amounts. Using the GoTo command, AutoHotkey jumps directly to the Animal_Onions: pointer for caramelizing the onions.
Since the process jumps into the middle of the Animal Style Cheeseburger subroutine, when the Animal Style Cheeseburger – Onions window closes, it automatically drops into the Animal_Sauce: routine. Next, the recipe must GoTo the Jack Stuffed Cheeseburger Label named Prepare: for shaping the burgers with Monterey Jack cheese inside. In order to make this jump decision, AutoHotkey must identify the currently running recipe subroutine: either Animal Style Cheese Burger (no Goto) or Jack Stuffed Animal Style (GoTo).
The initial menu selection tells us which recipe track to follow. The menu name (A_ThisMenu) identifies the Jack Stuffed Animal Style recipe:
Placing this condition into the MessageSetup: subroutine identifies the origin of any mixed-use menu steps. AutoHotkey determines the proper path by checking the value of the StuffedAnimal variable. For example, after the Animal_Sauce: window, the process uses the following check:
If (StuffedAnimal = 1)
If running the Jack Stuffed Animal Style sequence (StuffedAnimal = 1), AutoHotkey jumps to the Prepare: point of the Jack Stuffed Cheeseburger routine. Otherwise, the Animal Style Cheeseburger continues dropping through its steps.
This same conditional format creates the jumps from Prepare: to the Animal_Buns: point and from Animal_Buns: to the Stuffed_Animal_Cook: point for the Jack Stuffed Animal Style steps. This process creates a new variation from older recipes without rewriting redundant steps. Often using the GoSub command (for Go Subroutine) works better, but in this situation, GoTo makes the routine act as if it’s one continuous series of steps.
GoTo Versus GoSub
To understand the difference between the GoTo command and the GoSub command, know that when a subroutine finishes, the GoSub command returns to the next line in the original calling routine, while the GoTo command does not. In most cases, since it returns to the same spot in the script, you’ll probably find the GoSub command (or a function) more appropriate. But if you know that you don’t want to return to that point, then feel free to use GoTo—but you better know where you plan to end up.
A common usage of GoSub runs the subroutine then returns to the next line after the calling line. For example, I moved the loading of the recipe variables for each step out of the auto-execute section of the script into separate Label subroutines, then replaced each with a single GoSub command. This made the script more readable by greatly reducing the length of the auto-execute section. In place of the code, I inserted the following GoSub command statements:
However, using the GoSub command in the mixed recipe scenario for the Jack Stuffed Cheeseburger Animal Style would have caused more problems than it solved. For example, if the GoSub command appeared in place of GoTo, then each call would create a new return point. That means clicking the Cancel button would cause the script to jump to the last GoSub call rather than exiting the thread. In many cases, jumping back would cause unwanted effects (e.g. display an inappropriate step from another recipe). In fact, even running through the entire recipe without canceling would cause an untold number of displays of various steps. After encountering the last Return in the subroutine, the final Return jump executes more GoSub commands—each creating an additional Return point. The GoTo command keeps it clean, allowing an exit with any Return encountered in any recipe sequence. To the user, each recipe (including the mixed) looks like a continuous set of steps.
While probably best avoided if GoSub or a function can do the job, the GoTo command works well in scripts emulating flow charts and plays an important role in decision trees. In those special situations, knowing where you are (and where you’re going) may be more important than where you’ve been.