I've had some trouble lately binding the UltraGrid to a custom collection. I've got a class hierarchy/organization as follows:
In my solution I've instantiated one of these custom collections (and added items to it) and set it to the grid's DataSource but what I see are the columns based on the two custom properties available from the collection class hierarchy (i.e. one from the base class and one from the derived class) rather than the properties of the business object (i.e. the type of the collection).
Interestingly when I try to use a binding source I do see the structure as initially expected but I get a type error when attempting to add items through the binding source.
Before delving too deeply into figuring out the binding source issue I'd like to know if there is some factor I'm missing when attempting to bind directly to the grid. Hope you guys can shed some light on this one.
thanks
Hello,
I am just checking about the progress of this issue. Did you able to isolate this issue in a simple sample, which we could investigate further for you. Let me know If you need any further assistance on this issue?
Thank you for using Infragistics Components.
Hello,
We are waiting for your code, in order to be able to investigate this issue further for you.
Thanks Mike, I'll post some code later on in the week - once I get a chance to have a look at this issue again and double check my own work.
zenophite said:That's exactly what I would have expected (and hoped for) as well, hence my surprise at seeing that the properties in the grid belong to the collection implementing IList itself rather than the base class typed item it is meant to contain....
I'm confused again. Are you saying that the grid is displaying the properties of the IList interface like Count? I don't see any way that could possibly happen. Unless your IList is also implemented ITypedList and return custom property descriptors for the IList interface - which seems unlikely since it makes no sense.
I think maybe we're having trouble communicating here because this is something of a complex scenario.
Out of curiosity, why implement IList yourself? Why not simply use List<T> or BindingLIst<T> and let the framework implement the interface for you. It's a lot less work and you can be sure that the grid will work with their implementation, whereas it's always possible that your own custom implementation will do something incorrectly.
Either way, I'm certain that if I could see the code, I could tell you exactly what's wrong. But there are just too many factors here to guess or list them all. Could you possibly create a small sample project which mimics your actual data structure and post it here so I can take a look? It would probably save us both a lot of time in the long run. :)
Mike Saltzman"] I'm having some trouble understanding some of your set up. What exactly do you mean by "custom property?" What's custom about it?
I'm having some trouble understanding some of your set up. What exactly do you mean by "custom property?" What's custom about it?
Nothing in particular...in retrospect I can see how that can make the description more confusing. I think I just wanted to emphasize the fact that the class had a single property in addition to the properties and methods that fulfill the IList interface. Sorry if that muddied the waters....
Mike Saltzman"] The WinGrid will bind to the structure that it gets from the BindingManager. If you bind the grid to a generic list of a base class, then the grid and the BindingManager will only reveal properties on the base class - it does not matter what the actual objects populating the list are.
The WinGrid will bind to the structure that it gets from the BindingManager. If you bind the grid to a generic list of a base class, then the grid and the BindingManager will only reveal properties on the base class - it does not matter what the actual objects populating the list are.
That's exactly what I would have expected (and hoped for) as well, hence my surprise at seeing that the properties in the grid belong to the collection implementing IList itself rather than the base class typed item it is meant to contain....
Mike Saltzman"] The WinGrid does not support displaying heterogenous data. All of the items in the list must have the same column structure. You cannot have a row with different columns that any other row in the same band.
The WinGrid does not support displaying heterogenous data. All of the items in the list must have the same column structure. You cannot have a row with different columns that any other row in the same band.
Right. Essentially the grid structure I had planned would consist of a single band showing the single Description property from the base class - about as homogenous as it gets :)
Mike Saltzman"] I've never heard of the BindingSource making any difference in a case like this. But maybe this is something new. I know there are cases where the BindingManager is unable to retrieve the data structure from the list and what it does in those cases is look at the first item in the list, or if there are no items, it will attempt to add an item, get the structure, and then cancel the new item. So maybe that's what is happening here.
I've never heard of the BindingSource making any difference in a case like this. But maybe this is something new. I know there are cases where the BindingManager is unable to retrieve the data structure from the list and what it does in those cases is look at the first item in the list, or if there are no items, it will attempt to add an item, get the structure, and then cancel the new item. So maybe that's what is happening here.
Hmmmm. Ok, I'll have a look. thanks.