This Technique Accesses Icons Embedded in Windows Folders for Inserting into Pop-up Menus—Plus, the New Combined Switch/Case Statement QuickLinks QL_GetIcon() Function
I completely rewrote the functions from the last blog for adding icons to the menus in the QuickLinks.ahk script combining the two into a shorter prioritized list using Switch/Case statements. In the process—after investigating how to read icons embedded in Windows folder/directory listings—I discovered an interesting Windows secret. It turns out that this procedure requires a totally different Windows maneuver than that used for reading Windows Shortcut file icons.
The Windows Desktop.ini File
When you embed an icon into a Windows folder (right-click on the folder name in Windows File Explorer, select Properties and the Customize tap, then click Change Icon… and browse for icons), rather than saving the icon path and icon number in the folder itself—as Windows does for shortcut files—it creates a special hidden file named desktop.ini in that same folder. With Windows set to Show Hidden Files, folder and drives in the View tab of the Folder Options window, you can view the hidden desktop.ini file in that folder. (Tip: You can use Ryan’s UnHideFiles.ahk script to hide and unhide files and folders.) Continue reading →
AutoHotkey Scripting Philosophy or Speeding Up the InstantHotstring.ahk script
“Before you can fix a problem you must understand it. Before you can understand a problem you must fix it.”
Sounds like a chicken/egg problem, but I assure you it isn’t. You only begin to understand a problem when you start working on a solution. As you grind through a script, you develop a deep awareness of its inner workings. I encourage any AutoHotkey novice to jump into a new script with both feet—even if you don’t think you know what you’re doing.
Sitting around and speculating about possible answers to a question often serves as mental thumb-twiddling. You must start somewhere—anywhere. Until you actually dig into it and undertake the work, you will never truly comprehend the obstacles and pitfalls associated with implementing a fix. You’ll find this singularly true when writing AutoHotkey scripts— especially as a beginner. The answer to the question “Where do I start?” is “Anywhere!” Continue reading →
If the Source Code for a Web Page Changes, You May Need to Rewrite Your Web Data-Driven Script, Plus More AutoHotkey Tips
Because I do a great deal of writing, I’ve fallen in love with my SynonymLookup.ahk script which pops up a menu of alternative words for instant replacement in my documents. It’s pretty cool—even if I do say so myself. However, the other day, it ceased working.
After highlighting a redundant word, I initiated the Hotkey combination searching for an equivalent term. Nothing happened! No matter how much time passed, the script displayed nothing.
A Look at a Manufactured Looping Technique Using the Goto Command to Ensure the Download of Web Page Source Code in an AutoHotkey Script
I ran into a problem with the SynonymLookup.ahk script. On occasion, the menu would appear showing only the original bold and bulleted search term as its sole menu item. This occurred when the script finished processing before downloading the source code from the Thesaurus.com page. As often happens when working on the Internet, the Web connection took a little too long to perform its job.
A common headache with any AutoHotkey script which uses the Web, the time it takes to interact with a site and download its content profoundly fluctuates. In the case of the SynonymLookup.ahk script, I needed to ensure that the variable containing the Web page source code existed and contained text before continuing to parse the synonyms.
Exploring the Existential Mysteries of AutoHotkey Code and How It’s Often Misunderstood
I’ve just published my latest book, Beginning Tips for Writing AutoHotkey Script, which endeavors to clear up some of the mystery surrounding the way AutoHotkey works. You’ll find grasping how AutoHotkey processes AHK scripts a tremendous help. Quite a bit of the confusion encountered by novice AutoHotkey scriptwriters occurs through misunderstandings about the manner in which everything (life, the universe, and AutoHotkey scripts) fits together. I wrote the book with that muddiness in mind. 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.