Grouping and Sorting Data

The Crystal Reports object model lets you examine how a report is sorted, grouped and what type of data is summarized. You can change many of these properties prior to running the report.

Since the sorting and grouping features of a report are so closely related, it makes sense that their classes are also closely related. Within these classes there is overlap because grouping is an advanced form of sorting. Grouping has more features and within each group you have to sort the records that it prints. The respective classes for sorting and grouping are shown in Figure 15-6.

Figure 15-6. The Sorting and Grouping object model.

Many of the classes have properties that are enumeration constants. These are documented in Figure 15-7.

Figure 15-7. Sorting and Grouping enumeration constants.

Sorting and grouping are both based on one thing: a field. The field determines what the sort order is and how the records are grouped. Whether this field is a report field, database field or a formula field isn’t important. But without a field you can’t have sorting or grouping. Thus, the field classes are shared throughout the class diagram and you need to understand how they are organized before you can work with sorting and grouping.

The ReportDocument.DataDefinition class has the collections that manage the sorting and grouping fields. Groups are managed with the Groups collection and the GroupNameFieldDefinitions collection. The primary means of working with these collections is by using a For Each loop.

The sort fields are referenced using the SortFields collection. The SortFields collection is a property of the DataDefinition object. Navigate through this collection using a For Each loop.

The SortFields collection stores SortField objects. The SortField object has properties that determine the sort field, sort direction, and whether it represents a simple record sort or a group. The SortField class is defined in the namespace CrystalDecisions.CrystalReports.Engine.

An interesting aspect about the SortFields collection is that it assigns a SortField object for each group in the report. This is because group fields have to be sorted prior determine what order the groups are printed in.

The grouping fields are referenced using two collections: Groups and GroupNameFieldDefinitions. These collections are a property of the DataDefinition object. Navigate through these collections using a For Each loop.

Both group collections have properties for storing the object’s name, the formula, the data type and whether it is a report field, formula field, etc. Since both collections give you the same information, the one you decide to use is more of a personal preference than a hard and fast rule. Each collection has its own pros and cons.

The GroupNameFieldDefinitions collection gives you more direct access to the group properties (e.g. the name, field kind, etc.). However, this collection has a lot of redundancy in it because it also has a reference to the Group object. Within the Group object is the ConditionField object and this object gives you the same information already in the GroupFieldNameDefinition object.

The Groups collection is pretty simple because it only references the Group object. Each Group object has all the information that you need and there is no redundancy. Another benefit is that the FieldDefinition class is the same class used to map the report fields and formula fields. This lets you quickly change the fields that a group is based on. You can also do this with the GroupNameFieldDefinitions collection, but not as direct.

To keep things simple, I will only use the Groups collection to work with the group objects. If you prefer to use the GroupNameFieldDefinitions collection, it is easy to modify the sample code.