Ah: the article I referenced was specifically about WPF DataGrid. A member of the Silverlight team has confirmed the issue with XO and Silverlight, and said something about a future release. But I see you found a workaround. I think I'm looking forward to your next steps more than you're looking forward to mine. <s>

Hank



>>Hmm... I had read that having the INotifyPropertyChanged interface implemented in XO (how many times will we write out ExpandoObject -- which for some reason puts me in mind of Spandex -- stretching to cover whatever is beneath <s>) allowed DataBinding.
>
>>
>>These posts ( http://stackoverflow.com/questions/1983033/how-do-i-dynamically-generate-columns-in-a-wpf-datagrid ) seem to support that idea.
>
>Dang! You should see the similarities of the approaches I took...
>I worked mainly on Winform and only sporadically on WPF, and there always without XAML.
>
>I ran headlong into [http://www.scottlogic.co.uk/blog/colin/2009/04/binding-a-silverlight-datagrid-to-dynamic-data-via-idictionary/#comment-5535]
>"However, unfortunately the PropertyPath syntax used for binding does not understand indexers, making it impossible to bind to a dictionary.
>
>Vladimir Bodurov presents an ingenious solution to this problem by dynamically generating a new Type based on the values present within the dictionary, i.e. If the dictionary contains the keys “Name” and “Age”, a Type will be generated that has properties of Name and Age."
>
>Which I resolved by half-dynamically creating [proof of concept] not via black magic ILM but by writing out C# from IPy and compiling that. Even here I would have to copy over from my OLEDB-Array. So the next step was to dynamically build ADO.Net Datatables and fill them from my already OLEDB-Typed Array rows, giving me the IObeservable interface without any further thougt. This works flawless and fast enough for small amounts of data [couple of hundred], which is the source of my hints to keep working with your DD data just in IPy. Readonly data works faster by directly setting grid cells.
>Still, this is copying twice the data from disk [worse than regular ADO.Net, urgh...] so for my next step I had set my task on harnassing a virtual DatagridView... Here I already experimented on the vfp side with an access method on vfp's "this" on a CA - similarities to Scott's

>public class Row
>{
>  private Dictionary<string, object> _data = new Dictionary<string, object>();
>  public object this [string index]
>  {
>    get { return _data[index]; }
>    set { _data[index] = value; }
>  }
>}

are quite obvious. Still, via his Dotnet Indexer I can probably map to my IPy OLEDB-Array an remove the ADO.Net layer to copy into if I ever run into middle sized client data sets as an intermediate step before tackling virtual DatagridViews.
>
>from other post
>>What VFP.Net did, however, was return .Net types for classes, something that has to be contrived in IPy.
>
>This is was "my" C# creator did: give me Dotnet-Compatible "baseclasses" with fields and property-functions via atrribute notation - like vfp.net classes with members defined in the "vfp" class definition part. Further IPy self.SetAttribute calls (aequivalent to vfp's addproperty()) would go to the IPy dict, but were not planned in this context
>
>perhaps I can revisit this in 2 months... looking forward to your next steps.
>
>regards
>
>thomas