BuyLog In
Ticket T271326
Visible to All Users
Duplicate

We have closed this ticket because another page addresses its subject:

GridControl hides columns defined by parent interface

XtraGrid IEnumerable<Interface> datasource

created 10 years ago

Hi,
When you use a list that contains object interfaces rather than the objects themselves (e.g List<IDisplayMe>), the PopulateColumns routine populates the grid with fields defined in the specified interface. Problem is that if the interface is a descendent of some other interface, the fields of that other interface are not included as they should be. The attached code shows an example where IClass3 descends from IClass2 which itself descends from IClass1. Class3 implements IClass3 and therefore must also implement IClass1 and IClass2. The form shows two grids, the datasource of the first is List<IClass3> and the second gets List<Class3>. The first grid displays only the field specifically defined by IClass3. The second grid (correctly) displays all the fields. It seems to me that PopulateColumns does a 'shallow' look at the properties and does not iterate over any hierarchy that may be present. This does not seem right to me.

\The driver for this is that we communicate with actual data from different databases and different structures. The data is used for different things- The implementation of these data connections packs/unpacks data into a common set of formats defined by interfaces and so the grid is unaware of nasty bits of implementation in the actual data classes themselves. e.g realworld:
The base interface contains common data for an 'event' of some kind: a name, a location, a description. The first child interface contains contains times and a guestlist. It's an event that is 'schedulable' but cannot be executed until a date is set for it. A descendent of the second interface provides the date and other stuff.  So it's possible to differentiate between a 'potential' event and an actual event as the potential event has no field for 'Date'.  But in at least one data display we want to see the lot. So we use interface3. Unfortunately all we see is the Date and Other Stuff…

In the example, I am aware that if I specify all the fields in I1 and I2 in I3 itself, the columns are populated correctly. But that makes no sense programmatically, generating messy code that is wayyy breakable, and makes 'subclassing' the interfaces a pointless exercise, even though in programming terms its bloody fantastic!

I would be interested in what you think about this. Have I missed something obvious?

cheers
>a

Sign in to comment on this post

Answers approved by DevExpress Support

created 10 years ago (modified 10 years ago)

Hi Andrew,

When a generic list is used as a data source, its fields are obtained by using the standard TypeDescriptor.GetProperties(T) method where T is the type of the list. If that type is an interface, the TypeDescriptor.GetProperties method will return only direct properties of the interface. So if you execute TypeDescriptor.GetProperties(typeof(IClass3)), you will get only the BOOL property. If you replace our GridControl with a standard DataGridView, you will see the same behavior. I've modified your project to illustrate this. I suggest you create your own collection and implement the ITypedList interface to return a collection of the desired properties in the ITypedList.GetItemProperties method. An alternative is to use unbound columns.

    Comments (2)
    AH AH
    Andrew Hilliar 10 years ago

      Hi Gosha, The ITypedList solution works well enough, but there's a bit of stuffing around with it (the object returned is readonly, so you can't iterate your contained interfaces. You have to do a seperate call on each and then manually create a PropertyDescriptor[], manually populate it with the discovered properties and then return that in a new one. Sighhhh.)
      I never thought the issue was a bug, just wondered if there was a better way around it. I take your point on the vanilla DataGridView. But if I wanted vanilla, I wouldn't have purchased DevExpress!

      DevExpress Support Team 10 years ago

        Hi Andrew,

        I assume that the PropertyDescriptor.IsReadOnly property of your property descriptors returns True. As a result, your fields are not editable. Check this. If you send us your project, we can research it as well.

        Unfortunately, we can't make our Grid support this scenario since under the hood, the standard WinForms binding mechanism is used and it does not support it.

        Sign in to comment on this post

        Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

        Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.