You can set the selection mode using the listbox widget’s -selectmode attribute, which, for the purposes of this book, must be one of the values in Table 13.1.

In browse mode, you can click and drag the selection with mouse button 1. If the selection mode is multiple or extended, you can select multiple items simultaneously, including items that aren’t adjacent to each other. In multiple mode, clicking mouse button 1 on a list item toggles its selected state but does not affect other items’ selected state.

In extended mode, clicking mouse button 1 on a list item selects it, unselects everything else, and sets the selecting anchor to selected item. If you then drag the mouse (with mouse button 1 pressed), you extend the selection to include all of the items between the anchor and the element under the mouse. You can also click an item to set the anchor and then Shift+Click (press the Shift key while clicking mouse button 1) on another item to select all of the items between the anchor and the Shift+Clicked item. Finally, in extended mode, to add a nonadjacent item to a selection, Ctrl+Click it (press the Control key while clicking mouse button 1).

Note: The Selection Mode Can Be Arbitrarily Defined

The default bindings defined for the Tk listbox widget expect the -selectmode attribute to be one of the values shown in Table 13.1. However, if you modify the bindings, you can use an arbitrary value to which your customized binding will respond. I do not address binding in this book, so I’ve stuck to the default attributes.

In Figure 13.9, I show how the multiple selection mode works while Figure 13.10 shows how extended selection mode works. To create Figure in 13.9, I modified list_create.tcl, adding -selectmode multiple to the listbox command:

listbox .colorlist -bg white -selectmode multiple

See select_mult.tcl in this chapter’s code directory.

Figure 13.9. Using -selectmode multiple makes it easy to select nonadjacent listbox items.

Figure 13.10. Click and drag to select multiple adjacent items in the extended selection mode.

To create Figure 13.10, I specified -selectmode extended when creating the listbox:

listbox .colorlist -bg white -selectmode extended

See select_ext.tcl in this chapter’s code directory.

You’re probably thinking something like, “Swell, Kurt. But how do I find out what items are selected?” Well, you’ll need a goat, a chicken foot, some blood, and... Wait, wrong book. The listbox widget has two commands for retrieving indices of selected items. They are:

As before, listbox does not refer to the listbox command itself, but to the name of a listbox widget or a variable reference to a listbox widget. Each of these commands is best used in different circumstances. The index command, for example, returns the numerical index that corresponds to its argument. In this case, I used the keyword active, which corresponds to the activated item in the list. It is best used when you are interested in the active element, which does not necessarily correspond to all of the selected elements. Table 13.2 lists other possible values for all listboxindex and other listbox operations that require index arguments.

If there are, or might be, multiple items selected in a listbox, the best command to use is listbox curselection, which returns a list of all the indices of selected items. For the Delete button in the color picker script I’ve been using in this chapter, the curselection command is the one I’ll use (more about that very shortly). Finally, if you know the index or indices of the listbox items in which you’re interested, you can use listbox get, passing it the index or range of consecutive indices. The useful feature of the get operation is that it returns the text of the specified items, rather than their indices.

Using what I’ve just discussed, the following listing shows yet another variation of the list_create.tcl script that enables you to delete all of the selected colors (see list_delete.tcl in this chapter’s code directory):

proc GetColors {colorFile} {
    set fileId [open $colorFile r]
    while {[gets $fileId line] > 0} {
        lappend colors [string trim [lrange $line 0 end]]
    }
    close $fileId
    return $colors
}

proc DelItems {w} {
    set s [$w curselection]
    set colors [lsort -decreasing -integer $s]
    foreach color $colors {
        $w delete $color
    }
}

listbox .colorlist -selectmode multiple -bg white
foreach color [GetColors "colors.txt"] {
    .colorlist insert end $color
}

button .bdel -text "Delete" -command {DelItems .colorlist}
button .bexit -text "Exit" -command exit

grid .colorlist -padx 5 -pady 5 -columnspan 2
grid .bdel .bexit -pady {0 5}

The real guts of list_delete.tcl reside in the DelItems procedure. It accepts a single argument, the widget on which to operate. The first set command retrieves the indices of selected items in the widget, storing this list in the variable $s. This is a junk variable, so I didn’t bother giving it a meaningful name. The next set operation sorts that list in descending numeric order. The reason I wanted the list in descending order was to preserve the ordering of items in the list as I deleted items. If I delete from the “bottom” of the list, the order of items above the deleted item won’t change. If I delete from the “top” of the list, each deletion changes the index value of all of the items below the deleted item. After sorting the list, deleting the items is a simple matter of iterating through the sorted list with a foreach and calling $w delete against each index value.

The other significant change to the script was wiring the Delete button to the new DelItems script. Figures 13.11 and 13.12 show the color list before and after deleting some randomly selected colors.

Figure 13.11. Select the colors you want to delete then click the Delete button.

Figure 13.12. The selected colors are gone!

Had I not sorted the retrieved indices in descending numeric order, instead of deleting the colors snow, GhostWhite, gainsboro, and OldLace, I would have deleted snow, white smoke, FloralWhite, and AntiqueWhite.

Another task you’ll surely want to perform is to select list items programmatically, that is, with code. Table 13.3 shows the operations you have at your disposal for performing selection-related activities in code.

The next script, auto_select.tcl in this chapter’s code directory, uses selection set to select the list items between index values 200 and 204 inclusive and the see command to scroll the selected items into view:

proc GetColors {colorFile} {
    set fileId [open $colorFile r]
    while {[gets $fileId line] > 0} {
        lappend colors [string trim [lrange $line 0 end]]
    }
    close $fileId
    return $colors
}

listbox .colorlist -bg white
set colors [GetColors "colors.txt"]
set i 0
foreach color $colors {
    set item [format "%3d %s" $i $color]
    puts $item
    .colorlist insert end $item
    incr i
}

button .bexit -text "Exit" -command exit
button .bselect -text "Select" -command {.colorlist selection set 200 204}
button .bscroll -text "Scroll" -command {.colorlist see 200}

grid .colorlist -padx 5 -pady 5 -sticky nsew -columnspan 2
grid .bselect .bscroll -padx 5 -pady {0 5} -sticky nsew
grid .bexit -pady {0 5} -columnspan 2

As with the other scripts in this chapter, auto_select.tcl is a modified version of list_create.tcl. In this case, I modified the foreach loop to show the index value of each item in the list in addition to its text string. I also added two button widgets to implement the selection (.bselect) and scrolling (.bscroll) functionality. .bselect’s -command attribute executes the command .colorlist selection set 200 204. The -command attribute for .bscroll, similarly, scrolls the list so that the item at index value 200 appears in the center of the listbox widget’s viewable area. Figures 13.13, 13.14, and 13.15 show the initial window, the results after scrolling the window (clicking the Scroll button), and the window after clicking the Select button, respectively.

Figure 13.13. The index values help you see the effects of the Select and Scroll buttons.

Figure 13.14. The Scroll button moves the item at index 200 to the center of the list.

Figure 13.15. Clicking the Select button programmatically selects the requested items.

In case you were wondering, you can also click the Select button first, followed by the Scroll button. I won’t get into the philosophical question of whether or not selected items are really selected if you can’t see them, but what I will guarantee is that when you click Scroll, the items I selected are, in fact, selected.

Block 1 consists of variable definitions. The $matches list stores a list of matched words and definitions created when the player clicks the Match button. The $items array is the source list of the words and definitions used to populate the two listbox widgets. It also serves as the master list against which the player’s matches are scored.

In Block 2, I define the MatchSels procedure, which is invoked each time the player clicks the Match button. I declare the global variables $lWords, $lDefs, and matches because I will be modifying them. $lWords stores the list of words extracted from the $items array, while $lDefs stores the list of definitions, also extracted from the $items array. I define these two variables later in the program, but I declare them here so I can access them inside the procedure.

To create the player’s match, I have to find out which items are selected and store the matched word and definition pair. The procedure is straightforward:

Finally, as a visual aid for the player, I change the font color of items that have been matched. Although the items aren’t actually disabled, making them gray emulates a common GUI idiom of “graying out” disabled items. The itemconfigure operation and its related itemcget operation allow you to set and retrieve, respectively, individual list items rather than the listbox itself or the list as a whole. Similarly, after completing the match, I clear the selected items using the selection clear operation to give the player a visual cue that I made the match and as a hint to continue.

The ScoreMatches procedure defined in Block 3 compares the player’s matches, stored in the $matches list, to the master list of words and definitions stored in the $items array. Again, these two variables are defined in the global scope, so in order to access them inside the procedure, I declare them as global variables. I also declare two procedure local variables, $correct and $incorrect, whose sole purpose is to keep track of the number of correct and incorrect matches.

The actual comparison is simple enough. Iterating through the player’s list of matches, I first break each pair of matched items into a word ($word) and a definition ($def). I compare the string value of the definition to the corresponding definition of $word from the $items array, using $word to index into the $items array. If the value returned by $items($word) is identical to $def, the match is correct, and I increment $correct accordingly. Otherwise, the match is incorrect, and I increment $incorrect. After iterating through each pair of matched items in the $matches list, I use tk_messageBox to display the results.

Block 4 defines and lays out the widgets I’ll need, two listbox widgets, a frame to hold the buttons, and the button widgets. I used the single selection mode on the listboxes to prevent the player from trying to match two words to a single definition (or vice versa).

I specified -exportselection false to make it possible to select items from more than one listbox at a time. By default, the listbox widget exports its selection to the X Window System selection buffer (the clipboard under Windows). Because there can only be a single selection buffer at any one time, you can only select items from a single listbox widget. I needed to be able to select items from more than one listbox; setting -exportselection false avoids this limitation. It also prevents selections from being accessed using the selection buffer (clipboard), but matches.tcl doesn’t need the selection buffer, so this wasn’t a problem.

I used a frame widget as a container for the buttons so the buttons would be nicely centered beneath the two listbox widgets. You’ll see why this is necessary when you get to Block 6. Beyond this one wrinkle, gridding out the widgets is routine.

The code in Block 5 parses the $items array, storing the words into the $words list and the definitions into the $defs list.

The code in Block 6 is somewhat more involved. The goal I want to achieve is to make each listbox just wide enough to hold the widest list item (measured in characters) and also to modify the order of items as I insert them into the listbox. If I don’t need to modify the order of the list items, the words and their correct definitions end up side-by-side in the two listboxes, which doesn’t present much of a challenge to the player.

First, I set the variable $wordLen to 0. At the top of the foreach loop, I sort the contents of the $words list in (ascending) alphabetical order. Then, for each item in the list, I check its length in characters. I use expr’s conditional operator (expr $wordLen > $newLen ? $wordLen : $newLen) to update the value of $wordLen if the length of the current word (stored in $newLen) is longer (if it isn’t, $wordLen is unchanged). Finally, I insert the current word at the end or bottom of the $lWords listbox. After processing all of the words on the $words list, I use the value of $wordLen to update the width of the $lWords listbox ($lWords configure -width $wordLen). The second foreach loop in Block 6 uses the same technique for the $defs list and the $lDefs listbox, so I’ll spare you a repeat of the explanation.

At this point, the setup is complete, and the game is ready to play.

Here are some exercises you can try to practice what you learned in this chapter: