The Media Center Sandbox

I have a scroller/repeater with a C# arraylistdataset backing store.

The list is sortable in one of three ways controlled by three buttons on the same page.  When a different sort order is selected, the C# code invoked :

1) does an arraylistdataset.Clear()

2) refills the arraylistdataset with the items in the new sort order

The weird thing that was happening was if the list was already scrolled down past the number of items that could be displayed on screen (in my case about 12 out od about 300), say, on index 20, clicking a button to change the sort order resulted in a blank list.  If the scroller were positioned such that the first element was visible, irrespective of which repeated item had focus, you could change the sort order as many times as you like and it was redisplayed properly.  That was the only criterion for a success .vs. failure scenario...whether the list was not fully paged up.  You could page all the way to the end, but if you wanted to change the sort order you had to page all the way to be beginning or nothing would be displayed.

I tried just about every solution under the sun to get this fixed finally arriving at the conclusion that the Clear() call must have been doing a notification to the scoller but if the first repeated item wasn't visible it would screw up.

I solved this by never clearing the list but just doing replacements of the items with their changed contents in the correct order, rather than a Clear() followed by adding them back in.

If anyone knows why these particular hoops need to be jumped through, for such a straightforward thing to do, I'd be interested in hearing an explanantion.

Oz

If you are using ModelItem objects in your ArrayListDataSet that correspond to the underlying data in your repeater (i.e. they expose properties that you want to sort against) then create an IComparer that does the sort for you, and sort the ArrayListDataSet using

arraylistdataset.Sort(new ByTitleComparer());

Where arraylistdataset is the name of the ArrayListDataSet instance, and ByTitleComparer is the name of the IComparer class that performs the sort.

When you perform the sort, because the ArrayListDataSet is bound to the repeater, the change will appear magically in the UI.

Cheers,
Andrew

Andy,

While I appreciate your reply it still doesn't explain why the repeated item list is all blank when the ArrayListDataset is Clear()'ed and not displaying item 0 at the time of the Clear().  If item 0 is currently displayed at the time of Clear()/rebuild then the resorted data appears just fine.  Page down and do the same thing and no data appears (although I know it is there, breakpoints in the C# addin show me this).  The repeated items are bound to a Choice property in the C# code which is a C# Choice variable whose Options is set to the ArrayListDataset.

I'll keep you suggestion in mind though for other projects where the sort order is less complicated.  When sorting by, say, Genre, I also want them in title order within the Genre so it is simpler to just refetch the data from the SQL database via the SELECT ... ORDER Genre,MovieTitle;  than writing a custom comparer to do a multi-key sort of my own.  I know how to do that, just would rather not bother.

Oz

The key thing with developing for Media Center is to try and go with the design rather than fight against it - you'll find stuff a lot easier and performing a lot more as anticipated if you do that.  The ArrayListDataSet and Repeater are designed so that inserting, removing or reordering items in the one, has an immediate visible effect in the other. 

The most likely explanation for the repeater issue is that you've found a bug as you're trying a scenario (making an item invisible in a repeater) that wasn't thought of by the designers of MCML and the UI renderer.  I'm just guessing though, as in Media Center the platform isn't as open or understood (by the community) as say, WPF.

I find the best way to deal with these kinds of problems is to open up a new project and recreate the issue in the simplest form possible.  If I can do that, I post it here in full so others can easily either a) tell me what I've done wrong, or b) confirm it doesn't work, and suggest other ways around it.

Cheers,
Andrew

Andy,

I'll do that.

Oz

I have encountered this repeater bug as well.  I have a context menu with a list of items that is determined by the type of the current item selected.  If the first menu item in my list is not available (and thus, visible=false) then the whole menu comes up blank - no matter how many other items should be in the list.

The really odd thing is that, if I move to another item where that first item is visible and bring up the menu it shows fine.  Then if I go back to the one where the first item is invisible and bring it up, it shows fine now as well.

So, long way of asking - was there ever any resolution or workaround to this issue of the whole repeater not showing if the first item is invisible?  It's a real problem in our app.  Thanks.

 

Hi Eric,

Okay, a theory (as in I'm guessing here): I think the size of each item may be determined by the size of the first item - if it's invisible, it causes the remaining items to be invisibile too.

Try setting the reference size in your repeater, see if that helps.

Alternatively, don't use invisible items in your context menu - instead create an ArrayListDataSet dynamically in the getter that returns an array of the items in the context menu array that don't have visible=false. That way, your array only contains visible items, but still gives the same functionality that you were expecting.

Cheers,
Andrew

Thanks for the help.  Setting MinimumSize in the repeater element did not fix the issue.  It did make the UI conform to that size, but it is still blank.

I wanted to use visible because it would allow me to have the list conform to the current selected item easily without having to completely re-build it everytime focus moves from one item to the next.  It seems turning on and off visibility is would be much faster than re-building the list with each focus event.

Just to check, it was the ReferenceSize I was referring to, not the MinimumSize

Cheers,
Andrew

Hmmm...okay.  I didn't see ReferenceSize as a valid element.  But, I did re-work the code to re-build the list and performance doesn't appear to have suffered.  That also allows me to know how many available things there are in the list (using count) which I couldn't do before because there was no way to know what was visible or not.  So, this is probably a better solution as long as it performs okay.

Thanks again for your help.