One of the first things you will notice when you`ll start using Xceed DataGrid for Silverlight is the fact that there is no SelectedItem(s) property. That's right. No SelectedItems property. 

The upcoming datagrid for Silverlight is a very different beast than today's current datagrids. It is built from the ground up to load and navigate through remote data sources extremely efficiently. It aims to make those remote data sources feel like they are completely loaded locally in your datagrid, without actually doing so. To achieve this, it takes data virtualization a few steps further than any other datagrid ever has. I talked about some of these advances in my post that introduces Xceed DataGrid for Silverlight. One of them is that everything this datagrid does happens asynchronously. This makes for a highly responsive user experience, but there are a few things developers will have to do differently in order to reap the benefits.

Although it may seem absurd, the decision to not have a SelectedItems property was not taken lightly, and many long discussions were had with proponents on both sides of the debate. So why is it not there? Simple. Because 95% of the time, it wouldn't work. Yes, 95% is an arbitrary number but it is a fair representation. The only way to keep your application responsive, even when the network isn't, is to use asynchronous data virtualization, which means to read and write data in the background. Having a synchronous SelectedItems property in this situation made no sense since the UI would have to wait for the selected items to be returned from the server. So we decided to go with a fully virtualized approach and created a selection model in which "selection ranges" are created. These ranges abstract the need to store the exact list of selected items and provide instantaneous selection across any number of items. If this process were done locally, the selection range would need to be processed as soon as it is created.

For example, let's say you have a large source with and the user selects a few items currently on screen. In this case, the SelectedItems property would return immediately since the items are already loaded. The UI wouldn't lock-up. But if the user selects a group of items and many of them aren't on screen, those would have to be immediately fetched from the data source before SelectedItems could return its value. The UI would freeze for an unpredictable amount of time while those items are returned, making your application feel sluggish.

This is why we exposed the BeginGetSelectedItems and EndGetSelectedItems asynchronous methods rather than a SelectedItem(s) property: we wanted you to be aware that requesting the selected items can be a costly operation and that in most cases, we could not guarantee if and when you would get the result. 

"But I absolutely MUST have a SelectedItems property!" Ok!

public IEnumerable<object> SelectedItems
{
   get
   {
      return ( IEnumerable<object> )GetValue( SelectedItemsProperty );
   }
   set
   {
      SetValue( SelectedItemsProperty, value );
   }
}

// Using a DependencyProperty as the backing store for SelectedItems. 
// This enables animation, styling, binding, etc...
public static readonly DependencyProperty SelectedItemsProperty =
DependencyProperty.Register( "SelectedItems", typeof( IEnumerable<object> ), typeof( MainPage ), null );

private void GetSelectedItems()
{
   IAsyncResult result = this.sldgDataGridControl.BeginGetSelectedItems( new AsyncCallback( this.ProcessSelectedItems ), null );

   if( result.IsCompleted )
      this.SelectedItems = this.sldgDataGridControl.EndGetSelectedItems( result );
}

private void ProcessSelectedItems( IAsyncResult result )
{
   if( result.CompletedSynchronously )
      return;

   this.SelectedItems = this.sldgDataGridControl.EndGetSelectedItems( result );
}

private void DataGridControl_SelectionChanged( object sender, EventArgs e )
{
   this.GetSelectedItems();
}