I have a class which implements your SL IPagedCollectionView interface, and largely based my code on what you've done in the Endless Paging example.
One thing I noticed, is that on any page change, both in your sample code and in my code, GetEnumerator is called more than once on a page change. This is pretty detrimental if I'm making several calls to the db for my data when I only need 1.
Been trying to step through with the debugger and cannot determine what's causing the problem.
5 Answers, 1 is accepted
Can you send us a sample project which demonstrates your implementation of the IPagedCollectionView interface (which is not our by the way, it is part of Silverlight) and the described behavior. We will attach this project to our source code and debug it in order to see what exactly is going on.
Thanks in advance.
Regards,
Ross
the Telerik team
Explore the entire Telerik portfolio by downloading the Ultimate Collection trial package. Get it now >>

The issue I'm describing exists in the ExamplesCS_WPF solution that can be downloaded right from your site. If you go into the DataPager.WPF project, SampleData folder, then place a break point on line 157 in the EndlessPagesCollectionView.cs and run the "Endless Paging" example, you'll see that it returns item.GetEnumerator() 5 times for each page change.
Thanks,
Tom
When a collection is not generic we have to do several things with it in order to try to get the type of the objects residing inside. That is why we get the enumerator more than once.
If you make your collection generic, i.e. deriving from IEnumerable<T> and having the method:
IEnumerator<T> IEnumerable<T>.GetEnumerator()
I hope this helps. All the best,
Ross
the Telerik team
Explore the entire Telerik portfolio by downloading the Ultimate Collection trial package. Get it now >>

Thank you for your response.
Would you mind sending me your modified version of EndlessPagedCollectionView?
I've modified my collection to implement IEnumerable<T> and am still seeing the enumerator called several times.
Thanks,
Tom
It appears that I have misplaced the breakpoint. Anyway, I debugged this again and saw what happens.
Unfortunately we can't avoid calling the enumerator since we need it for many different reasons -- to determine the count of the items, to determine their common base type in case there are different items in the collection, to add them to our inner list and so forth. I will not go into further details here. Furthermore, both the pager and the grid point to this collection and both controls attempt to get the enumerator.
So long story short, we really can't lower the method call count without actually breaking part of our functionality.
Here is a possible solution. You can create an cache internal List inside your class implementation. If GetEnumerator is called and your list is null or empty, you can create it and fetch the current page from the DB, i.e. on demand. Then you store this data in the list and return the list each time someone from the outside world calls GetEnumerator. When someone from the outside world changes the page, i.e. calls the IPagedCollectionView.MoveToPage(int pageIndex) method, you can invalidate, i.e. nullify your list. So the next time someone calls the GetEnumerator method, your list will be null again and you will go to the DB and fetch the new page. And so on...
The idea is to cache the data and return it from GetEnumerator as long as no one changed the page. When the page changes you will invalidate the cached data and get the new page data and return it until someone changes the page again.
Maybe this will help.
Ross
the Telerik team
Explore the entire Telerik portfolio by downloading the Ultimate Collection trial package. Get it now >>