Your Privacy Matters: We use our own and third-party cookies to improve your experience on our website. By continuing to use the website we understand that you accept their use. Cookie Policy
1233
Binding to an interface that inherits from another interface
posted

If I am binding a grid to a binding list of a given interface using an ultradatasource, and the interface inherits from another interface, is there a way to bind to the parent properties?

 Public interface y
{
 Datetime audit;
}
Public interface x : y
{
 string x;
}

I am binding the grid to interface x, but I also want to include the properties of interface y.  I have confirmed that if I don’t inherit y and include those properties my objects work.  The problem is that that I pass interface x to routines that accept interface y.
Parents
No Data
Reply
  • 469350
    Verified Answer
    Offline posted

    Hi,

    You lost me a little there when you mentioned UltraDataSource. If you are binding to a List, where does UltraDataSource come into it?

    Anyway, the grid will display the properties that the DotNet BindingManager tells it to. There's really very little control over this in the grid itself.

    I think if you bind the grid to BindingList<x>, then this list implements ITypedList and returns only the properties of x. 

    There are several ways you can get what you want here, though.

    1. Use a BindingList<y>, instead of BindingList<x>. This is pretty obvious and I assume since you are posting here, it's probably not an option for you.
    2. Use unbound columns. You could add an unbound column to the grid for each property of y. You would do this in the InitializeLayout event. You would then use InitializeRow to populate the grid cells from the underlying ListObject of the row after casting it into type y. For any editable fields, you would have to update the ListObject of the row, probably in the BeforeCellUpdate event of the grid.
    3. You could derive from BindingList<x> and re-implement ITypedList to include the properties of type y. This would mean creating derived property descriptors. It's a bit tricky if you haven't done it before and has essentially the same problem as option 1.
Children