MVC Widgets - List Selections

Last Updated: May 5, 1996

Previous Lesson: List
Next Lesson: What's Next?

The selection mode

So now we think we understand how the list part of an MVCList works - how about the selections? Well, the first thing to understand is that the way we express the selection or selections depends upon the "mode" of the widget: whether it's single select or multi-select. The SelectionInList model can handle both of these modes, but you have to know what you're doing and only ask the appropriate questions. For instance, it's up to you to ask either selection() or selections(), depending on the mode.
In either case, the SelectionInList object holds onto a selectionIndexHolder, which (by default) is a ValueHolder. What this ValueModel holds onto depends upon the mode, as we'll see below.
In Smalltalk, you have to choose either a SelectionInList model or a MultiSelectionInList model for the life of the component.

Single selection lists

If the list component is single-select then the selectionIndexHolder will contain either an Integer (which corresponds to the 0-based index of the selection) or null (if there is no selection). SelectionInList implements a number of methods that makes dealing with single-select easy:

selectionIndex() will return an int which corresponds to the selected index, or SelectionInList.NO_SELECTION if there is no selection.

selectionIndex(newInt) will set the current selection index when passed an int.

selection() will return the Object that is selected, or null if there is no selection.

selection(newObject) will set the selection to the newObject, or deselect everything if newObject isn't in the list or is null.

The method names are identical in Smalltalk, with the main difference being that the selection index is 1-based, so a selection index of 0 corresponds to no selection.

Multiple selection lists

If the list component is multi-select then the selectionIndexHolder will contain a Vector of Integers. SelectionInList implements a number of methods that makes dealing with multi-select easy:

selectionIndexes() will return a Vector of Integers which correspond to the selected indexes, or an empty Vector if there are no selections.

selectionIndexes(newVector) will take a Vector of Integers and set the selection indexes.

selections() will return a Vector of Objects which are the selected objects, or an empty Vector if there are no selections.

selections(newObjects) will take a Vector of Objects and set the selections to those objects.

The method names are identical in Smalltalk, with the main differences being that the selection index is 1-based and the collection class used is a Set.

The SelectionHolder object

One method you can send to a SelectionInList object, selectionHolder(), will create a very useful object: a SelectionHolder object. This is a ValueModel that appears to hold onto the selection(s) of the list. As you'll see in the examples, this is really handy when you start "wiring" your ValueModels together.
In Smalltalk you can send the method #selectionHolder to get an AspectAdaptor that has the same behavior.

Example 8: MVCList selections

We're getting near the end with these examples, so I expect you'll be able to follow the source code without too much additional information. In these next couple of examples, you should start to pick up on a different mindset of application building. Traditionally, your application class is responsible for building the window and properly responding to all the events through the life-time of the application. MVC programming is quite different. The main purpose of the application class is to "wire" the model to the view using ValueModel classes, and then to sit back and watch things work. Notice how little the applications have been doing after the init() method.

Anyway, let's extend Example 7 to show detailed information about a selected player. In this example (look at the source code), we'll have the list of players in the left side and a "detail view" on the right side. The detail view will consist of two pieces of information: a read-only field with the selected player's name and an editable field with the player's shooting percentage. As we switch selections in the list, we should see the details on the right also change. The layouts are getting a little more complex, so I've switched to using the FractionalLayout layout manager for laying out the components.
The Smalltalk version of this example can be found in Example8.st and can be started by evaluating "Example8 open".

Example 8

Example 9: Team browser

This example is very similar to the last one, but we will tie everything together. In addition to having a list for the players, we'll add another list for the teams. When you select a team, the list of players will update. When a player is selected, the detail view on the right is updated. You may want to check out a diagram of this example, which may help you understand the source code.
The Smalltalk version of this example can be found in Example9.st and can be started by evaluating "Example9 open".

Example 9

Conclusion

There - we've taken care of a widget that can be a real pain to work with: the list. If you understand what's going on, the rest of the MVC widgets are kid's stuff. We'll wrap up in the next lesson.

Previous Lesson: List
Next Lesson: What's Next?

Go back to the tutorial introduction.

The selection mode
	So now we think we understand how the list part of an MVCList works - how about the selections? Well, the first thing to understand is that the way we express the selection or selections depends upon the "mode" of the widget: whether it's single select or multi-select. The SelectionInList model can handle both of these modes, but you have to know what you're doing and only ask the appropriate questions. For instance, it's up to you to ask either `selection()` or `selections()`, depending on the mode. In either case, the SelectionInList object holds onto a selectionIndexHolder, which (by default) is a ValueHolder. What this ValueModel holds onto depends upon the mode, as we'll see below.	In Smalltalk, you have to choose either a SelectionInList model or a MultiSelectionInList model for the life of the component.
Single selection lists
	If the list component is single-select then the selectionIndexHolder will contain either an Integer (which corresponds to the 0-based index of the selection) or null (if there is no selection). SelectionInList implements a number of methods that makes dealing with single-select easy: `selectionIndex()` will return an `int` which corresponds to the selected index, or `SelectionInList.NO_SELECTION` if there is no selection. `selectionIndex(newInt)` will set the current selection index when passed an int. `selection()` will return the Object that is selected, or `null` if there is no selection. `selection(newObject)` will set the selection to the newObject, or deselect everything if newObject isn't in the list or is `null`.	The method names are identical in Smalltalk, with the main difference being that the selection index is 1-based, so a selection index of 0 corresponds to no selection.
Multiple selection lists
	If the list component is multi-select then the selectionIndexHolder will contain a Vector of Integers. SelectionInList implements a number of methods that makes dealing with multi-select easy: `selectionIndexes()` will return a Vector of Integers which correspond to the selected indexes, or an empty Vector if there are no selections. `selectionIndexes(newVector)` will take a Vector of Integers and set the selection indexes. `selections()` will return a Vector of Objects which are the selected objects, or an empty Vector if there are no selections. `selections(newObjects)` will take a Vector of Objects and set the selections to those objects.	The method names are identical in Smalltalk, with the main differences being that the selection index is 1-based and the collection class used is a Set.
The SelectionHolder object
	One method you can send to a SelectionInList object, selectionHolder(), will create a very useful object: a SelectionHolder object. This is a ValueModel that appears to hold onto the selection(s) of the list. As you'll see in the examples, this is really handy when you start "wiring" your ValueModels together.	In Smalltalk you can send the method `#selectionHolder` to get an AspectAdaptor that has the same behavior.
Example 8: MVCList selections
	We're getting near the end with these examples, so I expect you'll be able to follow the source code without too much additional information. In these next couple of examples, you should start to pick up on a different mindset of application building. Traditionally, your application class is responsible for building the window and properly responding to all the events through the life-time of the application. MVC programming is quite different. The main purpose of the application class is to "wire" the model to the view using ValueModel classes, and then to sit back and watch things work. Notice how little the applications have been doing after the `init()` method.
	Anyway, let's extend Example 7 to show detailed information about a selected player. In this example (look at the source code), we'll have the list of players in the left side and a "detail view" on the right side. The detail view will consist of two pieces of information: a read-only field with the selected player's name and an editable field with the player's shooting percentage. As we switch selections in the list, we should see the details on the right also change. The layouts are getting a little more complex, so I've switched to using the FractionalLayout layout manager for laying out the components.	The Smalltalk version of this example can be found in Example8.st and can be started by evaluating "Example8 open".
	Example 8
Example 9: Team browser
	This example is very similar to the last one, but we will tie everything together. In addition to having a list for the players, we'll add another list for the teams. When you select a team, the list of players will update. When a player is selected, the detail view on the right is updated. You may want to check out a diagram of this example, which may help you understand the source code.	The Smalltalk version of this example can be found in Example9.st and can be started by evaluating "Example9 open".
	Example 9
Conclusion
	There - we've taken care of a widget that can be a real pain to work with: the list. If you understand what's going on, the rest of the MVC widgets are kid's stuff. We'll wrap up in the next lesson.