Adding Folders and Files from Windows to AutoHotkey Menus

After a Little Pondering, I Found Adding Windows File Explorer Structures to an Action Menu Simple

I was wrong when I contemplated using the BoundFunc Object to insert folder and file names into an AutoHotkey action menu. At the time, I thought that the AutoHotkey Menu command did not offer enough flexibility to handle the task on its own. Those concerns included:

  1. The limited number of built-in menu variables severely constrained the information available when clicking a menu item.
  2. Duplicate folder names found in any other folder or subfolder would cause a conflict.

Both of these problems have solutions, but I was afraid that I would need to resort to some complicated gymnastics.

Sometimes, we know too much for our own good. With a toolbox full of tricks, we often devise methods which—although they work—make the coding more complex. Then, rather than rethinking the problem, we dig a deeper hole. That’s how I started out with the rewrite of the barebones QuickLinks script. Rather than stripping the question down to the basics, I started looking for solutions to problems that don’t actually exist.

AHK_user dealt with the menu name problem in “QuickLinks (Menu by folder)” by deriving menu names from the full directory path. This ensured no duplicates for any of the submenus. I surmised that I would need to do something similar.

The script loads folders and subfolders into menus and submenus.

Then, it occurred to me, “Why not just use the folder full path as the menu name?” If it worked, I would not need any Regular Expression manipulation of the folder path and name, plus, I would avoid menu name duplication. I realized that I could also drop the BoundFunc Object for passing data. It all seemed too easy.

Continue reading

Barebones AutoHotkey QuickLinks App

After Many Years, It’s Time to Take Another Look at the QuickLink.ahk Script

Since its early beginnings, the QuickLinks.ahk script (originally introduced as a replacement for the missing Windows 8 Start Menu in January 2013) has evolved both through this blog and others working through the AutoHotkey forum. It has grown in complexity which can make it a little difficult to modify for personal use. Recently, I took a closer look at the core of my version of QuickLinks.ahk and decided that the time has come for a rewrite—at least of the central code.

During the intervening years, I’ve learned a few things and feel I can build a cleaner more universal basic program—at least for the main routine. The same may apply to many of the added features. (Sometimes starting over makes the most sense.)

Continue reading

How to Neutralize Errant Hotstrings (AutoHotkey Trick)

Take Advantage of Hotstring Precedence to Deactivate Unwanted Hotstrings Firing

Sometimes AutoHotkey Hotstrings fire at the wrong time. For example, whenever I put the word AutoHotkey into a document I prefer the full word rather than an abbreviation (AHK). I use “ahk” as the Hotstring—replacing it with “AutoHotkey” in almost all cases.

However, when I started adding the same extension to my scripts, I would get “IPFind.AutoHotkey” rather than the “IPFind.ahk” that I needed. This was exacerbated by the fact that the preceding dot ( . ) caused a Hotstring reset making some of the usual fixes unavailable. I needed to disable “.ahk” as a Hotstring.

The two requirements for neutralizing an errant Hotstring include:

  1. The new Hotstring must appear in the script before the primary Hotstring. The first form of a Hotstring found in the script takes precedence over any following Hotstrings using the same trigger.

    Note: Hotstring precedence only applies to Hotstrings loaded from the same script. The most recently loaded identical Hotstrings from another script takes precedence over any previously activated Hotstrings.

  2. Reset the Hotstring trigger without any replacement.

The following set of Hotstrings disable auto-replacement whenever preceding the activation term “ahk” with a dot ( . ) while continuing to replace all other lower-case forms of “ahk” with “AutoHotkey”:

:B0C?:.ahk::
:C:ahk::AutoHotkey

When activated, the B0 option prevents backspacing, the C option ensures an all lowercase trigger, and the ? option causes immediate execution. Effectively, the activation makes nothing happen—except resetting the Hotstring trigger. AutoHotkey recognizes “.ahk” and does not replace it. Any other form of all lowercase “ahk” triggers “AutoHotkey” as its replacement.

You’ll find other, more complex methods for dealing with special Hotstring situations but sometimes all you want a Hotstring to do is nothing.

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.)

jack

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.)

Find my AutoHotkey books at ComputorEdge E-Books!

Find quick-start AutoHotkey classes at “Robotic Desktop Automation with AutoHotkey“!