Two-Deep Variables for Tracking Data (AutoHotkey Trick)

When You Find No Obvious Way to Link Specific Data to an Object or Another Value, You Might Try Saving It to a Variable within a Variable

Sometimes you encounter a scripting situation where saving data to just any random variable doesn’t do the job. While creating variables and storing values is simple enough, you may find it difficult to recall those values at the right time. It’s important to know you’re getting the right data when you want it. Maybe using the value of a variable as a variable name (two-deep) will give you what you need. Continue reading


Create Multiple GUI Pop-Ups in a Single Script (AutoHotkey Scripting)

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

How to Write Easy-Merge AutoHotkey Scripts (Technique Example)

These Steps Make Integrating Your Script Into Combo Apps Simple

In my last blog, “Encapsulate AutoHotkey Code for Multi-Script Integration and Portability (Scripting Techniques)“, I explained how to hermetically seal the auto-execute section of a script, then make variable and code object names unique—thereby reducing the risk of conflict within other scripts when building combo apps. By doing this, the script turns into a robust entity easily added to any other .ahk script while continuing to stand on its own as an independent app. As the example for this blog, I’ve rewritten the ScreenDimmer.ahk script. ScreenDimmer(I explain in detail how ScreenDimmer.ahk works in the e-book AutoHotkey Applications—which offers numerous AutoHotkey tips and tricks while reviewing all of the available AutoHotkey GUI (Graphical User Interface) pop-up controls with practical demonstrations of how to use each.) Continue reading

Encapsulate AutoHotkey Code for Multi-Script Integration and Portability (Scripting Techniques)

Run Your AutoHotkey Scripts as Standalone Apps or Add Them Unaltered to Master Scripts by Creating Hermetically Sealed Auto-Execute Modules

If you’re anything like me, you’ve written a number of scripts which you use regularly. You can run each app separately assuring that they don’t conflict but that tends to load the Windows System Tray with too many icons—making it a little difficult to track all of them.

On the other hand, combining the scripts into a single file presents problems of its own. Any script which contains its own auto-execute section must run this part of the code when it first loads. Simply using the #Include directive won’t do the job. Place it in the top of the file and the other script modules, such as Hotkeys, Hotstrings, and Label subroutines, stop the processing of the original auto-execute section. Yet, if you place the #Include at the bottom, AutoHotkey never sees or runs the new auto-execute section. The novice scriptwriter often solves the problem by breaking apart the script and separately adding the auto-execute section to the top of the master file while locating all the other code modules toward the end of the file.

Continue reading

Using Unique Icons for Specific Windows Shortcuts (AutoHotkey Menu Tip)

Draw Icons for AutoHotkey Menus Directly from Windows Shortcuts

I talked extensively in an earlier blog about adding icons to the menus in the QuickLinks.ahk script by using the FileGetShortcut command. This AutoHotkey command digs out data such as the target program from the shortcut. At the time, I didn’t attempt to use the captured icon data (OutIcon and OutIconNum—icon location and number respectively) because, in most cases, the variables came up blank. Even using the standard context menu creation option (New⇒Shortcut) often did not save the icon data for viewing with GetFileShortcut. Frankly, that would have made the process too easy.

Continue reading

Add Secret Windows Tools (God Mode) to QuickLinks Menu (AutoHotkey Tip)

This Windows Trick Works in Vista, Windows 7, 8, and 10

I first wrote about this hidden Windows technique years ago. You can find many references to it by searching the Web for the term “Windows God Mode” but I don’t know how many people make regular use of this feature. Continue reading

New Version of QuickLinks AutoHotkey Script

Many Changes to QuickLinks.ahk Previously Discussed, Plus a Few New Features Not Yet Covered! Now Available for Download!

I’ve finally posted the latest version of QuickLinks.ahk which includes all of the discussions from the past few weeks—plus a couple more features and fixes which I plan to talk about in the near future. Continue reading