Let's start with what CDInfo is in the example. When you data bind a repeater you have to pass it a collection of items. Those items can be anything: strings, integers, objects, etc, but they tend to be collections of objects. When you reach the ItemDataBound event in the repeater, however, you are not working the collection, you are working with a single item from that collection, and that item is located in the e.Item.DataItem (e is the EventArgs parameter, and it could be named differently). Since e.Item.DataItem is defined as an Object, you have to cast it from an Object into whatever type of object you actually need.
So, my assumption in the example was that people would be binding a collection of CDInfo objects to the Repeater. The code
((CdInfo)e.Item.DataItem
Is simply casting the current data item into a CdInfo object. And the code
GetTrackInfo((CdInfo)e.Item.DataItem);
Is my way of saying, hey, you need to get the track information for the CD. The method itself should return a collection (an array, IEnumerable, IEnumerable<>, etc) object containing the track information for the current CD. And then you bind that collection to the inner repeater and you should have a hiearchy that looks like
CD1
TRACK 1
TRACK 2
...
CD 2
TRACK 1
TRACK 2
...
LINQ is good at building out object hiearchies so you probably don't need an actualy method to find the track info, it's probably already there. So you're code may simply look like
NestedRepeater.DataSource = ((WhateverYourLinqObjectIs)e.Item.DataItem).Tracks;
And if you are getting the same tracks for each CD, you may want to check on the objects before the repeater is even involved to make sure the LINQ objects are being populated correctly. If not, then you're problem is further upstream. If so, then it's something directly in the repeater binding code.
Damon Armstrong, Technology Consultant
[
Blog] [
Articles]