Once Loaded into an AutoHotkey GUI ListView, You Can Add Tools for Editing Data

With the exception of the first column, AutoHotkey does not allow direct editing in a GUI ListView control. That forces us to create separate editing controls for changing and updating content in any of the other columns. We can either add the controls to the same GUI as in the AddressBook.ahk script (shown below)—discussed in my AutoHotkey Applications e-book—or we can create a second GUI which pops-up on demand. Since putting all the controls in the same GUI creates less confusion for the ListView functions (the functions always operate on the default GUI), you might find the AddressBook.ahk example easier to implement for your application.

However, for the sake of doing something different (and to get a better understanding of the ListView control), here, we create a second GUI window just for editing the LegalInput.ini data table. In this alternative two-window approach, keeping track of multiple GUIs sets up the challenge.

This blog demonstrates how to modify the data within the ListView control. Next time, we’ll alter the routine to simultaneous update the data table INI file.

The ListView Editing Window

By assigning a second name to the new editing GUI (LV_Edit), we initiate a window for displaying, changing, and updating all but the first column (Hotstrings):

Gui, LV_Edit:Add, text, vHotstring w50
Gui, LV_Edit:Add, Edit, vShortDef w200
Gui, LV_Edit:Add, Edit, vLatin w200
Gui, LV_Edit:Add, Edit, vLongDef r3 w200
Gui, LV_Edit:Add, Button, , Submit
Gui, LV_Edit:+OwnerLegalList

Since we won’t alter the Hotstring column, we use the GUI, Add, Text command to add a text field. (Remember, per earlier blogs, we must create unique values for each Hotstring key, otherwise, the INI data table file won’t locate any redundant keys found in the first column. Therefore, at least for now, any editing of Hotstring keys must occur directly in the file with a text editor.)

Note: I posted the working LegalListView.ahk script at the “ComputorEdge Free AutoHotkey Scripts” site. This file shows how all the code discussed in the first three blogs of this series integrates into the app. I’ll update the script as I add more blogs to this series.

The next three Gui, Add, Edit commands set up editing fields for the short definition (ShortDef), the Latin term (Latin), and the long description (LongDef). The Submit button (Gui, LV_Edit:Add, Button, , Submit) initiates any updating action.

We add the Gui, LV_Edit:+OwnerLegalList option to prevent the editing window from disappearing behind the ListView window when we click or make a new selection in the main GUI. The +Owner option ties the smaller editing GUI to the larger main window. Whenever you minimize or show the main window the owned window follows suit.

When activating the gLabel subroutine (gMyListview) in the original Gui, Add, ListView line of code, we get the following pop-up window:

The gMyListView subroutine activates through a number of Gui Events, most notably the left-mouse double-click. (Clicking the column header also initiates the gLabel. We must trap this option to limit and enhance its behavior. See how at the end of this blog.) To limit when the subroutine activates, we compare the value of A_GuiEvent to “DoubleClick”:

MyListView:
If (A_GuiEvent = "DoubleClick")
{
  Row := A_EventInfo
  LV_GetText(Text,Row)   ; default first column value
  LV_GetText(ShortDef,Row,2)
  LV_GetText(Latin,Row,3)
  LV_GetText(LongDef,Row,4)
  GuiControl, LV_Edit:Text, Hotstring, %Text%
  GuiControl, LV_Edit: , Edit1, %ShortDef%
  GuiControl, LV_Edit: , Edit2, %Latin%
  GuiControl, LV_Edit: , Edit3, %LongDef%
  Gui, LV_Edit:Show
}

The built-in variable A_EventInfo contains the row number whenever the double-click Gui Event occurs. Using the LV_GetText() function, AutoHotkey retrieves the text from each column in the selected row. Then, using the GuiControl command, we insert the ListView text into the editing fields. Note that the script calls out the name of the editing window (LV_Edit) for each instance.

Tip: If you assigned variables to each editing field (e.g. vShortDef, vLatin, vLongDef), you can use those names rather than the standard Edit1, Edit2, and Edit3:

GuiControl,LV_Edit: , ShortDef, %ShortDef%
GuiControl,LV_Edit: , Latin, %Latin%
GuiControl,LV_Edit: , LongDef, %LongDef%

This may save confusion in more complex AutoHotkey scripts.

Now that we have placed the row data in an editing window, how do we update the ListView with any edits?

Updating the ListView Table

Our LV_Edit GUI includes a Submit button for saving the changes. For now, we’ll only renew the ListView table values and save updating the INI data file for next time. That means the changes only take effect on the screen. Reloading the file returns the data to its original form.

When clicked, the Button GUI control assumes a standard Label subroutine name when no gLabel option appears in the Gui, Add, Button command. AutoHotkey builds the name from the Gui name (if any) plus “Button” plus the button text. In this case, LV_Edit + Button + Submit (i.e. LV_EditButtonSubmit), as follows:

LV_EditButtonSubmit:
  Gui,LV_Edit:Submit
  Gui, LegalList:Default
  LV_Modify(Row, , , ShortDef, Latin,LongDef)
Return

The Gui, Submit command saves the new text from the editing fields in the associated variables. Next, we reset the default GUI (Gui, LegalList:Default) so the ListView functions know where to do their work. (More keeping track of GUIs.)

AutoHotkey V2.0 Note: If you only use one ListView control in one GUI window, then you won’t encounter these GUI name/default problems. This awkwardness remains a part of AutoHotkey version 1.1. In AutoHotkey V2.0, GUI control commands turn into objects, each with their own assigned name. This solves the confusion problem and helps demonstrate why work advances on AutoHotkey V2.0—although, if you’re satisfied with V1.1, you should feel no pressure to upgrade when (or if) V2.0 comes to fruition. (For more information on the future of AutoHotkey Version 2.0, see “A Peek at the Coming AutoHotkey V2.0.”)

The LV_Modify() function uses the saved values to update the text in the ListView. You should consider this a temporary update. Although the changes immediately appear in the ListView window, AutoHotkey does not save them to the data table file. That requires the IniWrite command—which I plan to discuss next time. For now, reloading the script wipes out the changes.

Keeping the Selected Record in Sight in ListView

One inconvenience may occur after selecting a row. When sorting rows by clicking the column headers, the selected row might disappear from the view pane—possibly scrolling out of sight. We correct this problem by locating the selected row (LV_GetNext()) and forcing it back into view (LV_Modify(Row, “Vis”)). We add the following conditional to the MyListView subroutine:

If A_GuiEvent = ColClick
{
  Row := LV_GetNext()
  LV_Modify(Row, "Vis") 
}

After clicking a ListView column header, AutoHotkey finds the selected row and scrolls it into the visible portion of the GUI.

Next time, we’ll use the IniWrite command to directly update the data table file.

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