GUI Menu Bar “Save” Item Complications (Part Two: Finishing AutoHotkey GUI Scripts)

Most Menu Bars Include Both “Save” and “Save as…” Options in the File Menu—Each Requires Special Considerations

As I mentioned last time, the act of adding a menu bar to a GUI can force the rethinking of many routines in the script. This time the consideration of the Save option(s) compelled me to reconcile potential problems when attempting to run the Save routine in the expected manner. First, knowing the actions activated by the Save Hotstrings button in the InstantHotstring.ahk script provides an understanding of the items required in the GUI menu bar.

The Save Hotstrings button in the InstantHotstring.ahk script executes the following tasks:

  1. First, the script opens the FileSelectFile window for filename selection or creation. This equates to the first step in the Save as… option in the menu bar File menu.
  2. If the filename exists, the user can opt to replace that file with new saved content or return to the selection window. This option also acts as part of the Save as… action in the menu bar File menu.
  3. The script offers the option to either overwrite the entire file or add (append) the active Hotstrings to the file. This equates to the new Append Hotstrings to File option in the menu bar File menu.
  4. AutoHotkey writes to the file and notifies completion. Without the notification, the action represents the desired instant save feature of an activated Save option in the menu bar File menu.
  5. Buried at the end of the Save Hotstrings button actions, the user encounters the option to set a file as the default startup load file. Adding the Set default file option to the menu bar File menu will make it easier for users to find and set this default.

In order to implement the four Save-type menu items shown in the new GUI menu bar File menu (image at beginning of blog), I need to separate the sequence of five decision points/actions into separate subroutines which the script can call independently—as appropriate for each item. Some menu items will need to call multiple subroutines while others (Save for instant file update) only one.

The Traditional “Save” Operation

Normally, a menu bar Save option (commonly operated with the CTRL+S key combination) writes any work in progress to the currently open file. When first opening a file, you may find the Save option disabled. But, after making changes to the content, the program enables the Save option in the menu bar and marks the file as changed in the title bar (often with the addition of an asterisk to the filename).

Then, hitting the CTRL+S shortcut automatically updates the open file replacing the old content and removing the asterisk in the title bar (and possibly re-disabling the Save option). In those cases where you don’t find the Save option disabled—and no open file—changed content usually causes the CTRL+S shortcut to initiates the Save as… option—facilitating the selection or creation of a filename.

This Save option works great for most text editing and word processing type files and makes the app fairly intuitive for Windows users. However, in the InstantHotstring.ahk script, I ran into a number of unwanted side-effects.

Problems When Saving Data in the InstantHotstring.ahk App

I want to add a quick single-shortcut Save option to the InstantHotstring.ahk script but I ran into a few obstacles:

  • While the app can parse, read, and activate Hotstrings from any file (.ahk or other text files), when saving, it overwrites a file with the active Hotstrings—potentially deleting all previous code. (Currently, using the Save Hotstrings button, the user can choose to append the Hotstrings to any file.) An automatic Save update to a third-party script could wipe out any other code (and comments) in the file—a dangerous option.
  • While an InstantHotstring.ahk generated file presents no problem for running an instant Save option, I need a method for distinguishing that generated file from any other AutoHotkey (.ahk) script.
  • Unlike most text editors, the routine doesn’t sense changes in content. When setting a new Hotstring, the script needs to set a changed-data variable.

If the script reads from an all Hotstrings-only file, the option to quickly write changes to the Hotstrings using the CTRL+S key combination would avoid the more tedious Save as… routine.

In order to implement a quick Save option, I need to resolve the above issues by:

  1. Developing a method for identifying an InstantHotstring format file.
  2. Disabling or trapping the Save menu option until both opening of an InstantHotstring file format as the default and detecting changes in the active Hotstrings.

These two steps should protect against accidentally overwriting non-InstantHotstring files while making it simple to instantly Save the new real-time active additions to the current InstantHotstrings format file.

In this blog, I talk about how to tag and detect the file format and disable the Save menu item. Next time, I will address how to detect content changes and enable the Save menu item.

InstantHotstring File Format

After realizing that I had written a script with the potential for destroying valuable AutoHotkey code by overwriting everything with a list of Hotstrings, I determined that I needed a method for distinguishing the InstantHotstring files from regular AutoHotkey scripts. My first thought turned to using a special file extension for these new files. However, since the files remain essentially .ahk files capable of running directly with the AutoHotkey engine, I felt that approach added too many complications.

Note: I may yet implement a special extension for the InstantHotstring generated files. The script can read any text file and a user could separately load the generated Hotstrings with the #Include directive and filename (including the new extension).

I settled on adding a header to each InstantHotstring file consisting of a one-line comment:

; InstantHotkey generated file

The TinyURL sends the users to my AutoHotkey scripts page. Whenever, the InstantHotstring.ahk script saves its active content to a file, it must mark the first line of the file with that header:

SaveFile := StrReplace(SaveFile, ".ahk", "")
If FileExist(SaveFile . ".ahk")
  MsgBox, 3, , Yes — Overwrite Old Hotstrings
                    !`rNo — Append New Hotstrings!
     IfMsgBox, Cancel
     IfMsgBox, Yes
        FileCopy, %SaveFile%.ahk, %SaveFile%.bak, 1
        FileDelete, %SaveFile%.ahk
        Head := "; InstantHotkey generated file"
        FileAppend , %Head%`r`n, %SaveFile%.ahk, UTF-8

The FileAppend command inserts the contents of the variable Head as the first line in a new file. (While this technique takes care of adding the header whenever saving a file, it does not address the app’s ability to append Hotstrings to an existing file—which, by the way, I just added as an option to the File menu.)

Recognizing InstantHotstring File Format

After tagging each InstantHotstring file with the special header, identifying the file only requires reading the first line of the file using the FileReadLine command:

FileReadLine, FileHeader, %OpenFile%, 1
If InStr(FileHeader,"InstantHotkey generated file")
  SplitPath, Openfile, FileName
  WindowTitle := FileName
  WinSetTitle, %WindowTitle%

If AutoHotkey identifies a file as an “InstantHotkey generated file”, the script saves the filename to the variable WindowTitle and uses WinSetTitle to fix the GUI title bar with the default file name.

Note: As a common practice, applications show changed-data status by adding an asterisk (*) to the title bar filename. When exercising the Save option, the app will remove the asterisk—a topic for next time.

Disabling the Save Option

When first loading the script and after executing the Save option, the Save menu item should appear disabled. This blocks unneeded instant saves.

Menu, FileMenu, Add, &Save`tCtrl+S, MenuBarAction
Menu, FileMenu, Disable, &Save`tCtrl+S

Next time, when adding the changed-data sensing code, the script enables the menu item:

Menu, FileMenu, Enable, &Save`tCtrl+S

Note: While I view this script as work-in-progress, I provide the current version of the new code for the curious. You can find the InstantHotstringMenuBar.ahk script on the Free AutoHotkey Scripts page. Although not yet operational, you can find the discussed changes in context. While these blogs demonstrate the techniques I plan to implement, the script requires a great deal more work before it’s ready for general use.

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

Find my AutoHotkey books at ComputorEdge E-Books!

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

3 thoughts on “GUI Menu Bar “Save” Item Complications (Part Two: Finishing AutoHotkey GUI Scripts)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s