how can I iterate over a nested .NET List<> in Visual Studio 2008's Crystal Reports?

Question

I have a Crystal Report in Visual Studio 2008 (C#). Its datasource is set programmatically at run-time to a .NET list, defined as follows:

List<visit_volume> Visits

a visit_volume looks like this:

public class visit_template
{
    private int _numberOfVisits;
    public int numberOfVisits
    {
        get { return this._numberOfVisits; }
        set { this._numberOfVisits = value; }
    }

    // other ints and doubles declared here
    // ..
    // ..

    private List<mEvent> _events;
    public List<mEvent> events
    {
        get { return this._events; }
        set
        {
            // updates _numberOfVisits here
            // ..
            // build-up a debugging string of each mEvent
            // ..
        }
    }
}

So, being fed into the Crystal Report is a List<> of visit_volume objects, which themselves contain a List<> of mEvent objects.

In Crystal Reports, I can see the contents of the Visits list, but I can't access and report on the contents of the events member - it just doesn't show. Is this because Crystal can't handle nested List<> structures, or am I doing something wrong?

Thanks in advance.

Answer 1

I think that although Crystal understands the 'outer' list as a datatable of rows, the data types of the fields inside that row must be standard database types. For example, if you were creating a SqlServer table and tried to add a field, it would not allow you to select a 'list' as the data type of that field.

I think that you may need to place all of the values from your nested list into a separate object/table, and then get Crystal to form a relationship between those two tables.

I'm not sure how you would supply both objects as the datasource - you may need to declare a dataset in Visual Studio, get Crystal to base its report on that structure, and then pass both objects through as separate tables in a .NET DataSet object.

Answer 2

Having thought about it, the answer to this might be to include a subreport which simply has the events structure as its datasource.