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,

Tim

I responded:

Hi, Tim,

1. To Escape special characters in AutoHotkey, use the backtick mark ( ` ). For example, “I want to use a comma`, in the InputBox prompt” (backtick then comma).
2. Add the following before the InputBox command for an always-on-top InputBox:

   Gui +LastFound +OwnDialogs +AlwaysOnTop

Hope this helps,

—Jack

This review of Gui window options got me thinking. I had an issue with the HowLongYearsMonthsDays.ahk script which would benefit from the Gui, +OwnDialogs option. (I now realized that over the years I could have made good use of this Gui command option in many other scripts.)

Whenever I click the Calculate button in the HowLongYearsMonthsDays.ahk script, a MsgBox pops up delivering the results. That’s fine, but if I don’t close the message box before entering new dates into the main GUI, the app falls unresponsive. The MsgBox command pauses the script in the subroutine. That forces me to close the message box before running another calculation. If I forget to close the pop-up message box or lose it under other open windows, I might think the script failed. The +OwnDialog option solves this problem.

By adding the +OwnDialogs option to the Calculate subroutine, I tie the MsgBox to the main GUI, forcing users to close the MsgBox before continuing. Until closed, you can’t interact with the main window.

The +OwnDialogs option makes “subsequently displayed MsgBox, InputBox, FileSelectFile, and FileSelectFolder dialogs” modal.

What Is a Modal Window?

Simply put, a modal window connects as a child to its parent window while preventing user interaction with that parent window. That means the parent window owns the child—both objects activating and deactivating in unison. Plus, when a modal child window, before users can interact with the parent window, they must close (execute or dismiss) the child.

AutoHotkey includes a number of options for creating a parent-child window relationship:

1. Gui, +OwnDialogs for  MsgBox, InputBox, FileSelectFile, and FileSelectFolder dialogs creating a modal child relationship.
2. Gui, MyGui:+Owner for AutoHotkey GUIs and other windows creates a parent-child relationship—although non-modal (allows interaction with parent window).
3. Gui, +ParentMyGui for AutoHotkey GUIs and other windows (similar to +Owner option with some variations).

Note: Items 2 and 3 operate in similar manners but they do not prevent interaction with the parent window (non-modal). I only tested the options in a limited fashion but +Owner allows the child to float freely while +Parent appears to lockin the position of the child window.

With both +Owner and +Parent, when you minimize the parent window, the child goes with it. Reactivate the parent and the child pops up as well.

The +Owner option looks like a good tool for creating floating gadgets which interact with specific other Windows programs (e.g. Paint)—yet, they close when you exit or minimize the main program. That way the gadgets remain corralled and attached to the main program.

To make +Owner or +Parent options modal (no interaction with the parent window), you must separately disable the parent window. Use the Gui, +Disabled option for AutoHotkey GUI windows or the WinSet, Disable command for other program windows.

Caution: If you disable a parent window to create a modal child window, you must enable the parent window again when you exit the child window. Otherwise, the parent remains inaccessible and you’ll find yourself using the Windows Task Manager to close the parent.

Creating Modal Dialogs in AutoHotkey

You must add the Gui, +OwnDialogs to the subroutine (e.g. ButtonOK) where you open the dialog object. The +OwnDialogs option only affects that subroutine or thread. In the HowLongYearsMonthsDays.ahk script:

SpanCalcButtonCalculate:
  Gui +OwnDialogs   ; makes MsgBox modal
  Gui, Submit, NoHide
  HowLong(Date1,Date2)
  MsgBox, , TimeSpan Calculation
      , Years %Years%`rMonths %Months%`rDays %Days% %Past%
Return

This solved my lost message box issue. I cannot interact with the main GUI until I close the message box. Plus, the message box stays always-on-top of the main GUI.

You need to add the option to any subroutine requiring modal dialog windows.

This parent-child relationship also works for other select AutoHotkey command objects. From the online documentation:

“ToolTip, Progress, and SplashImage windows do not become modal even though they become owned; they will merely stay always on top of their owner. In either case, any owned dialog or window is automatically destroyed when its GUI window is destroyed.”

When using the dialog objects listed, I recommend implementing the +OwnDialogs option as a “Best Practice” in all your AutoHotkey scripts. This forces the user to deal with the pop-up dialog prior to moving on. Otherwise, your script might act like its broken when an open dialog window disappears behind other windows.

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