Silverlight: ReadOnlyList Recommendation

Silverlight: ReadOnlyList Recommendation

Old forum URL:

MadGerbil posted on Monday, August 29, 2011

I've read only list that is used as the datasource for a combobox that appears in a datagrid.

How would you recommend that I fill that read only list?

I could fill it and use it as a property off the BusinessListBase.  I don't care for that a whole lot because it doesn't seem to belong there and I may need to use this list in other places.

I could fill it and stick it in the cache but I don't care for that because the list can change (it is configurable based on the contents of another list).

The most logical place seems to be as a property on the ViewModel because it would be easy to plug in on other ViewModels - which is really selling me on the MVVM pattern now that I think about it.

How does that sound?

MadGerbil replied on Monday, August 29, 2011

I'm a little worried about syncronization here.

What happens if the objects in the datagrid are retrieved and the datagrid populated before my combobox items are retrieved and populated?  I'd have two async operations running and there is no guarantee one will get done before the other.   Is this an issue?

JonnyBee replied on Monday, August 29, 2011


That is one of the resons why we often use the UnitOfWork (UOW) pattern.

The UOW would consist of a UOWRoot object that is responsible for retrieving

This also simplifies setup of datasources as you do not have to worry about syncronization.

The UOW object will usually be a readonly root object and contain an EditableRoot or EditableRootList object to be saved later on.



MadGerbil replied on Wednesday, September 07, 2011

Thank you for that response.

I've managed to set my objects up that way and I've part of it working but I've run into what I hope is a minor roadblock.   I'm using a ReadOnlyBase object that has an EditableRootList and a ReadOnlyList.   The EditableRootList is the ItemsSource for a SilverLight 4.0 DataGrid and it works very well.  The part that hurts my head is that I'm not sure how to set the combobox to the ReadOnlyList.

It isn't the combobox that is the problem - I understand how to use them and I've them working successfully elsewhere in the project (static data sources).  The problem is with Silverlight because the DataContext on the DataGrid is set to the EditableRootList and the combobox has no way to get back up the object graph to get to the ReadOnlyList.

So, the ReadOnlyRoot object is the DataContext for the UserControl and the EditbleRootList is the datacontext for the DataGrid.

How do I wire up the combobox (child of the datagrid) to the ReadOnlyBase.ReadOnlyList?

MadGerbil replied on Wednesday, September 07, 2011

Got it working by using a collectionviewsource as a staticresource.

Thanks Again.

RockfordLhotka replied on Wednesday, September 07, 2011

That's exactly what I do. Frequently I find that a CVS resource can index into properties of my "root" model object or viewmodel in ways that you can't do with a binding expression.

And I don't mind that, because the CVS adds sorting and that sort of thing, so it is generally a benefit.

MadGerbil replied on Wednesday, September 07, 2011

Another problem: When I change the value of one combobox they change for the entire grid.

In my resource dictionary for the usercontrol I have this:

<CollectionViewSource x:Key="Users" Source="{Binding Path=UserDisplays}"/>

In my datagrid I've got this code:

<sdk:DataGridTemplateColumn Width="120" Header="Assigned">
SelectedValue="{Binding Path=ContactUserId, Mode=TwoWay}"
ItemsSource="{Binding Source={StaticResource Users}}"

RockfordLhotka replied on Wednesday, September 07, 2011

Just like in Windows Forms, XAML has this concept of currency when it comes to any list. Something manages currency (which item is current), and that's the CVS.

So if you need multiple concepts of currency, you need multiple currency managers.

MadGerbil replied on Thursday, September 08, 2011

I'll be honest.

I'm shocked at how difficult it is to get a freakin' combobox to work in a datagrid.   I've done windows forms development, asp development and so forth for the past 10 years and I cannot believe the hacks one has to go through to get such a simple control to work in Silverlight 4.   The team has really, really failed on that point - it's really that bad.   I've got a regular observable collection working on a datagrid as the itemssource for a combobox but I'm having real issues with getting a list gathered from the database to work.

There is so much I love about Silverlight but after making so much progress on the learning curve only to be stymied by a combobox for 3 days - it's incredibly frustrating.   Every single hack/workaround I've tried has been a failure - it's like the tech blocks anything/everything.   Some of the hacks I've found on the web I just don't want to use because I shouldn't have to write a 200 line derived class to repair what should be a very basic, easy to use control.

Sorry about the rant but it's enough to make me can the entire project and just use different technology.

MadGerbil replied on Thursday, September 08, 2011

1: You should be able to bind a combobox in a datagrid to an ancestor of the datagrid but this cannot be done in Silverlight.   It's my understanding that ElementID works in WPF but not Silverlight.

2: You should be able to create a static resource from the datacontext of the host usercontrol and then use that static resourceto act as the ItemSource of the combobox contained within the datagrid but I've not been able to discover a way to make that happen.

3: As a workaround I created a class with a static property on a do-nothing class that holds my list.  The list is populated when the ViewModel is created and I create a staticresource from that static property (I know 'static' in those two instances doens't mean the same thing) and use that staticresource as the ItemsSource for my combobox.  It works fine.

Sometimes I hate my job.

I'd quit Silverlight but it looks so wonderful and it's still better than the hell that is HTML.

Copyright (c) Marimer LLC