Chapter 26. Data Entry, Data Views
| For generations of programmers, one of the most common jobs has been the creation of programs that facilitate the entry, editing, and viewing of data. For such a program, generally you create a data-input form that has controls corresponding to the fields of the records in a database. Let's assume you want to maintain a database of famous people (music composers, perhaps). For each person, you want to store the first name, middle name, last name, birth date, and date of death, which could be null if the person is still living. A good first step is to define a class containing public properties for all the items you want to maintain. As usual, these public properties provide a public interface to private fields. It is very advantageous that such a class implement the INotifyPropertyChanged interface. Strictly speaking, the INotifyPropertyChanged interface requires only that the class have an event named PropertyChanged defined in accordance with the PropertyChangedEventHandler delegate. But such an event is worthless unless the properties of the class fire the event whenever the values of the properties change. Here is such a class.
Implementing the INotifyPropertyChanged interface lets the properties of this class participate as sources in data bindings. They cannot be targets because they are not backed by dependency properties, but usually it's enough that they can be sources. The OnPropertyChanged method is not required, but it provides a convenient place to fire the PropertyChanged event, and classes that implement the INotifyPropertyChanged interface usually include such a method. Some classes define the OnPropertyChanged method to have an argument of type PropertyChangedEventArgs, while other classes define it as I've done, which involves somewhat less code overall. The next step is a data-input form. You could use a Window or a Page for this job, but the most flexible solution is a Panel of some sort. The following PersonPanel class uses a Grid to display three TextBox controls for the first, middle, and last names, and two DatePicker controls (from the CreateDatePicker project in the previous chapter) for the birth date and death date. Label controls identify each of the data-input controls.
Notice that the three TextBox controls contain bindings to their Text properties, and the two DatePicker controls contain bindings to their Date properties. Each of these bindings has a Path property that indicates a particular property of the Person class, and each of the bindings has an explicit TwoWay mode setting so that any change to the control will be reflected in the source data. In addition, the TextBox bindings have the UpdateSourceTrigger property set to PropertyChanged so that the source data is updated whenever the Text property changes and not (as is the default behavior) when the TextBox loses input focus. These bindings are incomplete because they are missing a data source. Generally this source is given as the Source or ElementName property of the binding, but another way to provide a binding source is through the DataContext property defined by FrameworkElement. The characteristic of DataContext that makes it so valuable is that it is inherited through the visual tree. The implications are simple and profound: If you set the DataContext property of a PersonPanel to an object of type Person, the TextBox and DatePicker controls will display the properties of that Person object, and any user input to those controls will be reflected in the Person object. This is how one binding between an object and a panel's DataContext property becomes multiple bindings between properties of that object and controls on the panel. The PersonPanel.cs code-behind file is trivial.
So that you can better grasp the mechanics of the binding between the Person object and the controls on the PersonPanel, the first project in this chapter loads and saves files containing only a single Person object. That's why the project is named SingleRecordDataEntry. Any database created from this program has only one record of type Person. The next part of the SingleRecordDataEntry project is a Window containing the PersonPanel input panel. I've also included a menu with New, Open, and Save items.
As you'll note, the three items on the File menu are associated with Executed handlers through command bindings. The PersonPanel object that occupies the interior of the DockPanel is given a name of pnlPerson. The three Executed event handlers are located in the code-behind file that completes the SingleRecordDataEntry project.
The New command (which is also simulated in the constructor of the class) creates a new object of type Person and sets it to the DataContext property of the PersonPanel. When you start up the program, you'll see the default values defined in Person displayed in PersonPanel. The Open and Save commands display OpenFileDialog and SaveFileDialog windows, respectively. These dialogs share the strFilter string defined at the top of the class and, by default, access files with the file name extension PersonXml. The OpenOnExecuted and SaveOnExecuted methods also make use of the same XmlSerializer object defined at the top of the class to store Person objects in XML format. The SaveOnExecuted method calls Serialize to convert the Person object currently stored as the DataContext property of the PersonPanel to an XML file. The OpenOnExecuted method loads a file saved earlier, calls Deserialize to convert it to a Person object, and then sets it to the DataContext property of the PersonPanel. You can save multiple files with the SingleRecordDataEntry program, but each file contains only one Person object. A typical file looks like this: <?xml version="1.0" encoding="utf-8"?> <Person xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <FirstName>Johannes</FirstName> <MiddleName /> <LastName>Brahms</LastName> <BirthDate>1833-05-07</BirthDate> <DeathDate>1897-04-03</DeathDate> </Person> The next obvious job requires maintaining a collection of Person objects. The .NET Framework contains several classes that store collections of objects. I tend to use the generic List class when I want something simple. But when working with databases, it's often advantageous to use the generic ObservableCollection class defined in the System.Collections.ObjectModel namespace. You can define a collection of Person objects like this: ObservableCollection<Person> people = new ObservableCollection<Person>(); Or you can derive a class (named People, perhaps) from the ObservableCollection class: public class People : ObservableCollection<Person> { } And then you can create an object of type People: People people = new People(); One advantage of the latter approach is that you can put some methods in the People class that save People objects to files and later load them. (This is the approach I took in the upcoming MultiRecordDataEntry project.) Because ObservableCollection is a generic class, you can add new objects of type Person to the collection without casting: people.Add(new Person()); You can also index the collection and the result is an object of type Person: Person person = people[5]; Beyond those two conveniences found in any generic collection class, ObservableCollection also defines two important events: PropertyChanged and CollectionChanged. The PropertyChanged event is fired whenever a property of one of the members of the collection changes. Of course, this only works if the ObservableCollection object is based on a class that implements the INotifyPropertyChanged event and which fires its own PropertyChanged event when one of the properties changes. (Fortunately, the Person class qualifies.) Obviously, ObservableCollection attaches an event handler to the PropertyChanged event of each member of its collection and then fires its own PropertyChanged event in response. The CollectionChanged event is fired whenever the collection as a whole changes, that is, whenever an item is added to the collection, removed from the collection, replaced, or moved within the collection. The MultiRecordDataEntry project includes links to the files Person.cs, PersonPanel.xaml, and PersonPanel.cs from the SingleRecordDataEntry project, as well as the DatePicker files from the CreateDatePicker project in Chapter 25. The People.cs file is the first of three new files for this project. The file defines a People class that derives from ObservableCollection to maintain a collection of Person objects.
I've also used this class for two methods named Load and Save that display the OpenFileDialog and SaveFileDialog windows and then use the XmlSerializer to load and save objects of type People. Notice that Load is a static method that returns an object of type People. Both Load and Save have arguments that you set to the parent Window object. The methods use this object to pass to the ShowDialog method and as a title in the two MessageBox.Show calls in case a problem is encountered with the file input or output. (Although putting the XmlSerializer code in the People class makes sense, normally I wouldn't also put the dialog boxes in there. There might be occasions when you'll want to load or save files without displaying dialog boxes. I've put the dialog boxes in the People class for convenience in simplifying the other programs in this chapter.) The MultiRecordDataEntry program uses PersonPanel to display the information for one person, and yet it deals with a file containing multiple people. To accomplish this feat, the program must have some provision for navigating through the database. One approach is to keep track of a "current" record, and to have buttons for navigating to the next record and to the previous record, and to go to the first record and to the last record. In the general case, you don't want to just view or edit the existing records of the file. You want to add new records and possibly delete records. In addition to the navigation buttons, you'll probably want to have buttons for Add New and Delete. The following file, MultiRecordDataEntry.xaml, defines the layout of a window that includes a menu with the familiar New, Open, and Save commands. The remainder of the window has a PersonPanel and the six buttons I've described.
The following MultiRecordDataEntry.cs file completes the definition of the program's Window object with event handlers for the three menu items and the six buttons. This class maintains two fields: an object of type People, which is the file currently loaded, and an integer named index. This index variable is the index of the current record displayed in the PersonPanel. This value indexes the People object and is altered by the event handlers for the First, Previous, Next, and Last buttons. With the Load and Save methods already defined in the People class, the three event handlers for the menu items are fairly simple. Both the New and Open items cause the creation of a new People object and a call to the InitializeNewPeopleObject method. This method sets the index variable to 0. If the People object has no records (which will be the case for the New command), this method creates a Person record and adds it to the collection. In either case, the DataContext of the PersonPanel is set to the first Person object in the People collection. A call to EnableAndDisableButtons enables the Previous button if the record being displayed is not the first record and enables the Next button if the record displayed is not the last record.
The event handlers for the six buttons are fairly straightforward. For the four navigation buttons, the event handler simply calculates a new value of index, uses that to index the people collection, and sets the DataContext property of the PersonPanel to that indexed Person object. The Add New button handler creates a new Person object and inserts it into the collection. The Delete button deletes the current record. If that results in an empty collection, a new Person object is added. The MultiRecordDataEntry program saves and loads files that look like this: <?xml version="1.0" encoding="utf-8"?> <ArrayOfPerson xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <Person> <FirstName>Franz</FirstName> <MiddleName /> <LastName>Schubert</LastName> <BirthDate>1797-01-07</BirthDate> <DeathDate>1828-11-19</DeathDate> </Person> <Person> <FirstName>Johannes</FirstName> <MiddleName /> <LastName>Brahms</LastName> <BirthDate>1833-05-07</BirthDate> <DeathDate>1897-04-03</DeathDate> </Person> <Person> <FirstName>John</FirstName> <MiddleName /> <LastName>Adams</LastName> <BirthDate>1947-02-15</BirthDate> <DeathDate xsi:nil="true" /> </Person> </ArrayOfPerson> Notice that the last Person element in this sample file is a living composer, so the DeathDate is null. This is indicated in XML using the nil attribute, as documented in the XML Schema specifications available at http://www.w3.org/XML/Schema. The logic connected with using the index variable to indicate the current record is referred to as a currency manager. The System.Windows.Data namespace contains a class that itself implements a currency manager, and some other important features as well. This class is CollectionView, and much of the remainder of this chapter will focus on CollectionView and its important derivative, ListCollectionView. As the names suggest, a CollectionView or ListCollectionView object is actually a view of a collection, which might be only part of the total collection or might be the total collection sorted or arranged in different ways. Changing the view does not change the underlying collection. You can create a CollectionView object based on a collection of some sort using the CollectionView constructor: CollectionView collview = new CollectionView(coll); The coll argument must implement the IEnumerable interface. The ListCollectionView class has a similar constructor: ListCollectionView lstcollview = new ListCollectionView(coll); However, the coll argument to the ListCollectionView constructor must implement the IList interface, which encompasses IEnumerable and ICollection (which defines a Count property), and also defines an indexer and Add and Remove methods. The static CollectionViewSource.GetDefaultView method returns a CollectionView or a ListCollectionView, depending on the interfaces implemented by its argument. (CollectionViewSource is also handy for defining a CollectionView in XAML.) A CollectionView object cannot sort or group its collection; a ListCollectionView object can. If you want to base a CollectionView object on an ObservableCollection, you can explicitly create a ListCollectionView because ObservableCollection implements the IList interface. The currency manager in CollectionView is exposed through several properties and methods. The Count, CurrentItem, and CurrentPosition properties are all read-only. You change the current position using the methods MoveCurrentTo, MoveCurrentToPosition, MoveCurrentToFirst, MoveCurrentToLast, MoveCurrentToPrevious, and MoveCurrentToNext. The class will allow you to move to a position one less than the index of the first item, and one greater than the index of the last item, and the IsCurrentBeforeFirst and IsCurrentAfterLast properties will tell you if that's the case. CollectionView also defines events named CollectionChanged, PropertyChanged, CurrentChanging, and CurrentChanged. In conjunction with using a CollectionView class, let's also reconsider the navigation interface. The .NET Framework 2.0 included a new Windows Forms control named BindingNavigator that displayed several graphical buttons to navigate through a database, and to add and delete records. I have attempted to duplicate the appearance of the Windows Forms BindingNavigator control in the following NavigationBar control.
The PNG files were obtained from the image collection that comes with Visual Studio. The code-behind file for the NavigationBar class defines two properties. The first property is named Collection of type IList. (It's anticipated that an ObservableCollection will be set to this property.) The set accessor uses the static CollectionViewSource.GetDefaultView method to create a CollectionView object, which will actually be a ListCollectionView object. The set accessor then sets event handlers to keep the navigation bar controls updated. The second property is named ItemType, and it's the type of the item stored in the collection. The NavigationBar requires this type to implement the Add New button. Otherwise, most of the logic is similar to the navigation buttons shown earlier. In addition, the NavigationBar allows the user to type in a record number, and the three TextBox event handlers at the bottom of the file keep that number within proper bounds.
The two files that comprise the NavigationBar class and the required image files are part of a library project named Petzold.DataEntry that creates a dynamic-link library named Petzold.DataEntry.dll. That project and a project named DataEntryWithNavigation are the two projects in the DataEntryWithNavigation solution. The DataEntryWithNavigation project has links to the Person.cs file, the People.cs file, the two files that make up the PersonPanel class, and the two files that make up the DatePicker class. The project also contains a XAML file and a C# file for the program's window. The XAML file defines a Window with a DockPanel. The familiar menu is docked at the top, a NavigationBar is docked at the bottom, and a PersonPanel fills the interior.
The code-behind file becomes fairly trivial. Like the original SingleRecordDataEntry project, it need only implement event handlers for the three items on its menu. For both New and Open, the event handler calls the InitializeNewPeopleObject method to link the People object with the PersonPanel and the NavigationBar.
The InitializeNewPeopleObject method first assigns the Collection property of the NavigationBar to the newly created People object. This Collection property in NavigationBar creates a new object of type ListCollectionView and attaches event handlers to maintain the navigation bar. The second statement of InitializeNewPeopleObject assigns the ItemType property of NavigationBar so that NavigationBar can create new objects and add them to the collection when the user clicks the Add New button. The last statement of InitializeNewPeopleObject assigns the DataContext of PersonPanel to the People object. This may seem strange. In previous programs, the DataContext property of PersonPanel has been assigned to a Person object so that the panel can display all the properties defined by the Person class. Assigning DataContext to a People object doesn't seem quite right, but it works. The People collection has been made the basis of a ListCollectionView, which is maintaining a current record, and that current record is what the PersonPanel actually displays. Although the NavigationBar might be a good solution for some data-entry programs, it isn't quite adequate when you need a good view of the overall array of data in the database. You might wish you had a ListBox available to scroll through the database and select items to view or edit. This approach is actually much easier than it sounds, and is demonstrated in the next project, which is called DataEntryWithListBox. The project requires the files contributing to the Person, People, PersonPanel, and DatePicker classes. The window is defined in the following XAML file and contains the familiar menu, a ListBox, and a PersonPanel.
The ListBox contains a definition of its ItemTemplate property under the assumption that the ListBox will be displaying items of type Person. A StackPanel with a horizontal orientation combines ten TextBlock elements that result in the display of items that look like this: Franz Schubert (17971828) The StackPanel is followed by a DataTemplate.Triggers section with two DataTrigger elements to fix two problems. First, if the DeathDate property is null, instead of displaying the Year property of the DeathDate I want to display the word "present" so that the entry looks like this: John Adams (1947present) Without that DataTrigger, nothing would be displayed after the dash, which is also an acceptable way of displaying the information. The second DataTrigger fixes a problem that results if the composer doesn't have a middle name. Normally one space separates the first name from the middle name and another space separates the middle name from the last name. If there's no middle name, two blanks separate the first name from the last name. The second DataTrigger eliminates one of those blanks. The window layout concludes with a PersonPanel and two buttons labeled "Add new item" and "Delete item." The navigation buttons aren't required because the ListBox allows scrolling through the items and selecting an item for viewing or editing. Here's the code-behind file.
Both the New and Open commands on the File menu result in a call to InitializeNewPeopleObject. This method creates a ListCollectionView based on the People object. As I emphasized earlier, a CollectionView is a view of a collection. The CollectionView defines a way of arranging the items of a collection for viewing, but this view doesn't change anything in the underlying collection. The CollectionView supports three general ways in which the view can be altered:
You can sort the items based on one or more properties. Filtering is the restriction of the view to only those items that meet certain criteria. With grouping you arrange the items in groups, again based on certain criteria. CollectionView supports three properties named CanSort, CanFilter, and CanGroup. The CanSort and CanGroup properties are false for a CollectionView object but true for a ListCollectionView. To sort a ListCollectionView object, you create objects of type SortDescription and add those objects to the SortDescriptions property. Here's how the DataEntryWithListBox program sorts the ListCollectionView by the LastName property: collview.SortDescriptions.Add( new SortDescription("LastName", ListSortDirection.Ascending)); The SortDescriptions collection can have multiple SortDescription objects. The second SortDescription is used if two properties encountered by the first SortDescription are equal. The SortDescriptions property defined by CollectionView is of type SortDescriptionCollection, and it has methods named SetItem, InsertItem, RemoveItem, and ClearItems for manipulating the collection. After defining a SortDescription, the InitializeNewPeopleObject method sets the ItemsSource property of the ListBox to this ListCollectionView: lstbox.ItemsSource = collview; The ListBox then displays all the items in the collection sorted by last name. That much should be obvious. But you also get a bonus. You are essentially linking the ListBox with the CollectionView so that the CurrentItem property of the CollectionView is set from the SelectedItem property of the ListBox. The ListBox becomes a means of navigating through the collection. This means that you set the DataContext property of the PersonPanel to this same CollectionView: pnlPerson.DataContext = collview; And now the PersonPanel displays the item selected in the ListBox, and you can use the PersonPanel to edit the item. The PropertyChanged events defined by Person, ObservableCollection, and CollectionView help the ListView update itself with every change. The remainder of the program shouldn't be difficult to understand. The event handler for the Add button adds a new Person object to the People class. That new Person object automatically shows up in the ListBox at the bottom of the list. The event handler continues by selecting that new object in the ListBox, which causes the properties of the item to be displayed in the PersonPanel. As you enter information in PersonPaneland particularly as you enter the person's last namethe item will not automatically get a new position in the ListBox as a result of the sort description. To re-sort the contents of the CollectionView based on new or altered items, a program must call Refresh. The particular place where you call Refresh will depend on the architecture of your program. Some data-entry programs allow a new item to be filled in and the Add button then adds that completed item to the collection. If you have such an Add button, you can add the new item to the collection and call Refresh at that time. In the DataEntryWithListBox program, there is no button to signal that an item has been completed. Instead, the program calls Refresh at the end of the AddOnClick method to re-sort the collection with any previously added items. This also causes the newly created Person item to be moved to the top of the list because the default string of "<last name>" precedes any alphabetic characters. Of course, you can add an interface to the program to sort by different fields. This is one way of facilitating searches for particular items. Another approach is called filtering. You restrict the CollectionView to only those items that satisfy particular criteria. To filter a CollectionView, you must have a method defined in accordance with the Predicate delegate: bool MyFilter(object obj) { ... } The argument to the method is an object in the collection. The method returns true if the item is to be included in the view, and false if not. You set the Filter property of the CollectionView to this method: collview.Filter = MyFilter; If you look at the definition of the Predicate delegate, you'll discover that it's actually a generic delegate defined like this: public delegate bool Predicate<T> (T obj) This fact might lead you to believe that you could define the filter method with an argument of any type. However, the definition of the Filter property in CollectionView calls for a method of type Predicate<Object>, so the filter method must have an argument of type object. The CollectionViewWithFilter program has links to the Person.cs and People.cs files and defines a window with XAML and C# files. The window includes three radio buttons that let you select whether you want to view living composers, dead composers, or all composers. Here's the XAML layout of the radio buttons and ListBox.
To keep this program relatively simple and focused, I didn't include a PersonPanel or buttons to add or delete items from the collection. The program simply lets you view an existing file based on the filter settings. You shouldn't assume from this program that once filtering enters the picture, you've lost the ability to enter new data. That's not the case. The Chapter 26 directory of the companion content for this book includes a file named Composers.PeopleXml with which you can experiment in this program and the next two programs of this chapter. The three RadioButton controls share the same event handler, which is located in the code-behind file. Based on the Name property of the three buttons, the handler sets the Filter property of the CollectionView to the PersonIsLiving method, the PersonIsDead method, or to null, which allows the display of all items.
At any time, there can be only one method assigned to the Filter property of the CollectionView. If you want to filter based on multiple criteria, the best approach is probably not to have a whole bunch of different filter methods, but to have just one filter method that you assign just once to the Filter property. This single method examines the object against all the criteria and returns a verdict. Whenever there's a change to the criteria, the program can call Refresh on the CollectionView to force all the items to pass through the filter method once again. One common use of filtering is a TextBox that lets the user type a letter or multiple letters. The ListBox then displays all the items in which the last name begins with those letters. This feature is easier to implement than it first seems. Here's a XAML file that resembles CollectionViewWithFilter.xaml except it has a Label and TextBox instead of a GroupBox and radio buttons. The TextBox has a Name property of txtboxFilter and a TextChanged event handler.
The code-behind file for the FilterWithText class prepares the window for a new CollectionView object by setting the Text property in the TextBox to an empty string, and assigning the LastNameFilter method to the Filter property: txtboxFilter.Text = ""; collview.Filter = LastNameFilter; The LastNameFilter method and the TextChanged event handler are both located toward the bottom of the code-behind file.
The LastNameFilter method simply returns true if the LastName property of the Person object starts with the text in the TextBox, with case ignored. Any change in the TextBox causes a call to the Refresh method to re-evaluate all the items in the collection. Besides sorting and filtering, a CollectionView can also group the items. The final program in this chapter will demonstrate this technique. To group items, you supply a method that assigns a group name (actually an object) to each item in the collection. Within the ListBox, the items are grouped by this name, but you can also supply custom headers and panels to differentiate the groups. CollectionView has a property named GroupDescriptions that is itself an ObservableCollection, and more specifically, of type ObservableCollection<GroupDescription>. GroupDescription is an abstract class with one derivative named PropertyGroupDescription, which you can use if you want to group items based on a property of the item. If this is not the case, you must define your own class that derives from GroupDescription. You are required to override the method named GroupNameFromItem. I decided I wanted the composers in the sample file to be grouped by the musical period they are associated with. Generally and approximately, these periods are Baroque (1600-1750), Classical (1750-1820), Romantic (1820-1900), and Twentieth Century (after 1900), but I added other periods I called Pre-Baroque and Post-War. Because my file doesn't store information about when the composers were active, I based my criteria on their birth years. Here's a class named PeriodGroupDescription that derives from GroupDescription and overrides the GroupNameFromItem method to return a text string for each item.
Let me show you the C# part of the window class first.
The OpenOnExecuted handler loads an existing People file, as usual, and creates a ListCollectionView object from it. The view is sorted by birth date, and a new object of type PeriodGroupDescription is added to the GroupDescriptions collections to group the items by the criteria in that class. The XAML file for the program's window has the same ListBox you're accustomed to seeing, but also includes a property element for ListBox.GroupStyle.
The GroupStyle property of ListBox is a collection of GroupStyle objects. If you have more than one GroupStyle object in the collection, you must also set the GroupStyleSelector property of ListBox to a method defined in accordance with the GroupStyleSelector delegate. This method gets a group name as an argument and returns a GroupStyle for that name. If you have only one GroupStyle, it applies to all the groups displayed by the ListBox. Each group can have its own Style (which you set with the ContainerStyle property), its own type of panel for displaying the items in the group (which you set with the Panel property), and its own HeaderTemplate. This latter property is the only one I took advantage of. I used it to define a TextBlock that displays white text on a dark gray background. The Text itself is a binding to a property named Name, which is actually the group name. Thus, each group is preceded by a non-selectable header that identifies the period with which those composers are associated. The grouping feature implemented by ItemsControl is very powerful and adds a whole other dimension to the data displayed in a ListBox. Not only can each item be displayed in a unique manner, but any consolidation of items can also have a unique identity within the control. It's one of those features that may not have an immediate application in your work. But on that day when a problem comes up that calls for ListBox groupings, you'll suddenly grow quite fond of this spectacular implementation. |
PropertyChanged; // Private fields. string strFirstName = "<first name>"; string strMiddleName = "" ; string strLastName = "<last name>"; DateTime? dtBirthDate = new DateTime(1800, 
EAN: 2147483647
Pages: 72