I am having some trouble with the UltraGrid design-time databinding to an EntityCollection.

If I use Bind To A DataSource it works in most respects except that the defined schema only goes to the second level of a hierarchy. For example using NW if I set EntityCollection to CustomersEntityFactory and Bind To the EntityCollection I get the first level Band "", and second level bands "CustomerCustomerDemo", "Employees", "Shippers", "Orders", and "CustomerDemoGraphics" but doesn't go down another level (i.e. OrderDetails). Is this the expected behavior? Showing all 3 levels does seem to work for a DataSet albeit the relations are stictly defined (i.e. create dataset, drag Customer, Order, and OrderDetail tables and define Relations).

If I use Manually Define A Schema and select Import Data From DataSource using EntityCollection I get a Null Reference exception. I can allievate the exception by selecting a DataMember, but then on the first level of the hierarchy is defined (i.e. EntityCollection of CustomerEntityFactory, choose EntityCollection as DataSource and Order as DataMember gives no exception but only order band).

Finally if I right click on EntityCollection and then cancel I get a NullReference exception.

Any ideas or suggestions?

Thanks

Infragistics' controls don't play nice when it comes to design time databinding as they assume a dataset being passed in, while what they should have done is just follow standards and read ITypedList's results. I can't do anything about this unfortunately...

I ran into the exact same problems. I have a work-around and a reply from Mike S, product manager of Infragistics for you:

Work-Around:

Generate a dummy DataSet from the database on your LLBLGen code is based. Check that the relations in the DataSet are named equally to the 1:n 'Fields mapped on relations' in LLBLGen. The relations will get translated to Bands in the Infragistics UltraWinGrid. Now at runtime just change the DataSource to your EntityCollection.

I had some trouble because there were several 1:n 'Fields mapped on relations' with the same name in my LLBLGen code and relation/Bandnames have to be unique. This can be solved by adding custom properties to the LLBLGen code like so:

[TypeContainedAttribute(typeof(QuoteArticleEntity))]
public virtual EntityCollection MainGroupArticle
{
    get
        {
            return this.QuoteArticle;
        }
}

There can be a bit more to it when your're working with inheritance. I'll leave that to your own imagination.

Now the reply from Mike S. I posted the following friendly message in the Infragistics WinGrid newsgroup:

Hello,

I just ran into the problem regarding multi-band databinding tot LLBLGen Pro EntityCollections. This problem is described in detail here: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=2477 .

In short it comes down to the UltraGrid not going deeper than two levels because apparently ITypedList results are not read correctly.

I realise support for LLBLGen EntityCollection's may not be on the top of your list, but it is one of the leading O/R mappers at this time.

Could you perhaps clarify the reason why there are some design-time data-binding issues and wether or not this will be improved in future releases?

Kind regards,

Ries Spruit

He gave me the following reply:

Hi Ries,

What version of the grid are you using? Do you have the latest Hot Fix? (Ries: Yes I do)
Despite what the thread here says, the grid does not, and never has, 

assumed that the data source is a DataSet. UltraWinGrid can bind to any data source that implements IList or IBindingList. I suspect this issue might be caused by the fact that the data source does not have any rows at some particular level and that some of the levels do not support adding. To give you some basic background, the grid gets the data structure (the columns) for each band from the BindingManager. The BindingManager gets the structure by looking at the first row of data in the list. If there are no rows, what the BindingManager will try to do is call AddNew on the IBindingList implementation and add a dummy row. It then gets the property descriptors of this temporary row, and then tells the IBindingList to cancel the row. This gets very complicated, as you might imagine. For example, if there are no rows in a parent list, then it becomes problematic to get the structure of the child list, since you need a parent row to add children to. The ITypedList interface is ideally suited to solve this kind of problem since it returns the PropertyDescriptors without requiring the existance of a row. The grid was updated earlier this year to take better advantage of ITypedList, so if you are using the latest version of the grid (and assuming that the LLBLGen object implement ITypedList), you should not have any problems.

Especially the last line makes me wonder why it still doesn't bind past the first two levels. Conclusion, both vendors say they adhere to the standard but in practice it doesn't seem to be like that. I think Microsoft should step in and point out the offender!

Kind regards, Ries