Saving Default Data in the Windows Registry (Part Six: Finishing AutoHotkey GUI Scripts)

Many AutoHotkey Users Save Settings in an INI File…However, the Windows Registry May Offer More Security and Stability

We tend to feel nervous about working with the Windows Registry. After all, a wrong step could conceivably cause harm to the operating system setup. Yet when taking the appropriate steps, this built-in Windows database can offer us a number of benefits:

  1. The Windows Registry is always there.
  2. It’s not easy to accidentally delete a Windows Registry entry.
  3. The average computer user won’t know where to find these special data entries.
Continue reading

Use Alternative Filename Extensions for Special Format Files (Part Five: Finishing AutoHotkey GUI Scripts)

While Changing the Saved Filename Extension in the InstantHotstring.ahk Script Helps Protect Original AutoHotkey Files, the Technique Offers Additional Benefits…Plus, a No-Wait Progress Bar for Instant-Saves

Over the course of the past few blogs, I added protection to files containing AutoHotkey code by both including a one-line file header and changing the saved filename extension to .hsf. These steps have resolved my concern about overwriting any AutoHotkey scripts—from which I may have extracted Hotstrings and loaded them into the “under-construction” InstantHotstringMenuBar.ahk app. At times, I thought that adding the two techniques might be overkill but now I’ve come to realize that using an alternative extension provides benefits that may prove even more useful than my initial attempt at protecting .ahk files.

Continue reading

Use the GoTo Command to Traverse Long Subroutines (Part Four: Finishing AutoHotkey GUI Scripts)

Sometimes the GoTo Command Makes Life Easier without Creating Perverse Effects

This next portion of the InstantHotstring.ahk menubar implementation did not go as I had expected. I thought that I would break up the routine launched by the Save Hotstrings button into separate subroutines or functions, then call each as appropriate for the corresponding Save/Append Hotstrings menu items (as seen in the image). I didn’t look forward to it because I knew it could get a little confusing. Some items would require multiple subroutine calls while others would need to just run—depending upon the menu selections made by the user.

I didn’t want to write redundant subroutines, but separating the various features of the complete routine required more than merely adding Return commands to encapsulate the code. I finally ask myself, “Why not insert AutoHotkey Labels into the main Save routine and use the GoTo command to jump my way through the decision points?”

Continue reading

Sensing AutoHotkey Editing Changes for Instant Save (Part Three: Finishing AutoHotkey GUI Scripts)

By Detecting Modifications in Edit Data We Know When to Activate Instant-Save Routines

Any change too active Hotstrings appends an asterisk (*) to the current open filename and enables the Save option.

In the last blog (“GUI Menu Bar “Save” Item Complications (Part Two: Finishing AutoHotkey GUI Scripts)“), I discussed the need to add a special header to a unique type of data file—InstantHotstring generated Hotstrings. This header helps to differentiate between AutoHotkey .ahk files—which you may not want to overwrite—and files generated by the InstantHotstring.ahk script.

When adding a Save option (instant-save using the CTRL+S key combination) to the menu bar, many Windows apps concatenate an asterisk (*) to the file name in the title bar—alerting the user to changes. In this blog, I add a similar change-detecting feature which both displays the appended asterisk and enables an instant-save routine.

Continue reading