Fixed the InstantHotstring.ahk Script Slow Hotstring Loading Problem

New Version of InstantHotstring.ahk Script Now Available!

I’ve rewritten the LoadHotstrings subroutine in the InstantHotstring.ahk script (alternate download) to overcome the slowdown created by using the pre-existing routines found in the original script, “AutoHotkey Script Speed Problems (Scripting Insights).” I simplified things by limiting the subroutine to:

  1. Adding Hotstrings directly from the file without extra processing—no interaction with the DropDownList GUI control.)
  2. Checking for duplicated or changed Hotstrings within a single variable.
  3. Activating each Hotstring as its added.

AutoHotkey exports the DropDownList GUI control contents just once into a single variable and only writes the new DropDownList after processing the entire target file. The test file of over 1000 Hotstrings loads in one to two seconds—depending upon the weather. (The old routine could take up to 70 seconds for that same file.)

You can find the new code (InstantHotstring(FastLoad).ahk) and the old code (InstantHotstring(SlowLoad).ahk) at the InstantHotstring.ahk section of the ComputorEdge Free AutoHotkey Scripts page.

I’m currently working on blogs which discuss both the philosophical and technical aspect of rewriting the subroutine.

Click the Follow button at the top of the sidebar on the right of this page for e-mail notification of new blogs. (If you’re reading this on a tablet or your phone, then you must scroll all the way to the end of the blog—pass any comments—to find the Follow button.)


This post was proofread by Grammarly
(Any other mistakes are all mine.)

(Full disclosure: If you sign up for a free Grammarly account, I get 20¢. I use the spelling/grammar checking service all the time, but, then again, I write a lot more than most people. I recommend Grammarly because it works and it’s free.)

Formatting Fonts and Colors in AutoHotkey GUI Window Controls

Guidelines for Setting Text Styles in AutoHotkey GUI (Graphical User Interface) Controls—You Can Make Your GUI Windows Easier to Read by Changing the Text Font and/or Color of Individual Controls

While AutoHotkey doesn’t offer the same detail control of color, font, and text style that you get in graphics programs, you can enhance your GUI pop-up windows with well-placed style changes. But to get the most from your adjustments, you need to understand how AutoHotkey executes these modifications.
Continue reading

Use Gui, +OwnDialogs to Glue Modal Dialogs Boxes to GUI Parent Windows (AutoHotkey Best Practice)

Save Confusion and Annoying Missteps by Creating Child Dialogs

I began working on the promised formatted date to DateTime Stamp conversion blog when I received this question from a reader:

Hi, Jack,

I’ve created a series of pop-up boxes to help me in doing telephone-service. I have two problems, both with InputBox:

  1. How can I put a comma in the prompt section? I tried things like \, and [,] but none work. I’m sure there must be a solution, but I can’t find it in browsing through your books.
  2. It is possible to include an “always on top” control for the display of an InputBox? It does not seem to work to put ”WinSet, AlwaysOnTop, ON, A” before or after an  Inputbox entry. Is there some way to make an Inputbox display automatically stay on top?

Many thanks,


Continue reading

Use BoundFunc Object [Func.Bind()] to Pass GUI Control Data (An AutoHotkey GUI Revelation)

Added as a Special Feature to AutoHotkey V1.1, You Can Quickly Bind Unique Data to GUI Controls for Passing to Functions—It’s Even Easier in V2.0. Add This One to Your Bag of AutoHotkey Tricks!

Sometimes in my explorations, I come across an unexpected gem. I dig into many aspects AutoHotkey merely because they exist—having no idea how a technique might affect my scriptwriting. Whenever I uncover a feature that switches on a light, I must admit I get a little excited. Interestingly, if I had not been rummaging through AutoHotkey V2.0, I may not have ever understood the significances of this latest revelation for GUI pop-up windows in V1.1 scripts.

*          *          *

GraphicSoundsIn a GUI (Graphical User Interface) pop-up window, passing the right data to a gLabel subroutine (or function) from a GUI control can get complicated. A couple of the more common methods includes calling the Gui, Submit command to store control values or using a technique for capturing control information, such as the MouseGetPos command or the special gLabel alternative function:

 CtrlEvent(CtrlHwnd, GuiEvent, EventInfo, ErrLevel:="")

While I can usually find a way to solve the data passing problem, I often find the answer awkward. Continue reading

Comparing Today’s AutoHotkey Version 1.1 and the Future Version 2.0 (Part 1—Everything Functions)

As We Await the Ultimate Release of AutoHotkey V2.0, Let’s Look at How Things Will Change

As I review the documentation for the alpha version of AutoHotkey V2.0, I can see that 95% of the code in a V1.1 script needs to change to run under the new version. AutoHotkey V2.0 offers a more consistent scripting environment, but you will experience a slight learning curve. Standard Hotstrings offer the only syntax which continues untouched. (Hotkey syntax also stays intact but you will need to update the commands within any Hotkey routines.) That means your AutoCorrect script will likely run fine under both versions of AutoHotkey—unless your Hotstrings execute custom actions.

To get ahead of the curve and give you a chance to make better-informed decisions about ever upgrading to V2.0 (once released), I offer this series of observations comparing V2.0 with V1.1. Digging into V2.0 requires a slightly different way of thinking yet it remains all AutoHotkey. You’ll find the overall script structure and how AutoHotkey processes a file unchanged. Any understanding you already possess about how AutoHotkey works will serve you well. In these blogs, I focus on converting from a language running with commands to one which uses corresponding functions.

Continue reading

AutoHotkey Version 2.0—Should I Wait for It?

ComputorEdge E-Books

As Signs of the Impending Release of AutoHotkey V2.0 Crop Up in the Online Documentation, Questions Arise About Our Legacy Scripts

I start by admitting that I have no special insight into AutoHotkey V2.0. I’ve had no contact with anyone who has the answers. I base all my thoughts on information freely available in the online documentation, forums, and other AutoHotkey sources. You might consider my words rank speculation—although drawn from my years of working with AutoHotkey V1.1. Since I written so many AutoHotkey books, you could even say that I hold a vested interest in the current version of AutoHotkey. In spite of all that, I offer this blog as an aid to current and future AutoHotkey users in their version decisions.

Continue reading

The Main Window for Debugging AutoHotkey Scripts

How to View the Inner Workings and Hidden Mechanisms of Running AutoHotkey Scripts

AutoHotkey includes a tool called the Main Window which aids with the debugging process. It gives you a peek into various aspects of a running .ahk script:

  1. Most recently executed lines of code (ListLines command).
  2. Current variables and values (ListVars command).
  3. Active Hotkeys (ListHotkeys command).
  4. Keyboard activity (KeyHistory command).

Main Window Menu

Open the Main Window by right-clicking on Windows System Tray icon of an active .ahk script and selecting Open from the top of the menu. The window pops open at the “Lines most recently executed” view. You can select the other three views plus “Refresh” from the View menu. Continue reading