I have a winform that allows several different searches. That is, based upon search options, a call to a wcf service uses a particular critieria object and returns a specific result set. The form itself is the same for all searches.
My challenge is configuring the ultradatasource to accept different shapes. So, first, I created a data structure with a generic result mapping to band 0 and list properties for each different result shape as separate child bands. I then set data binding to the parent object and the datamember pointing to the correct collection property. This binds the data, but only for the fields that exist in both the parent and child object. Additionally, the column headers do not reflect the child band, even though I configured the root band column headers to be invisible.
To complicate matters, I was using interfaces to present the binding shape and the PropertyDescriptorCollection to walk the chain of interfaces, which will not happen by default. I've used this approach many times to ensure I present to the grid that which is expected, but it did not work in this case.
So, to simply matters, I bound directly to lists, removing the interfaces and property descriptors. Unfortunately, the results did not change.
Next, I decided to set the data binding directly to the list collection and pass null as the data member. Same results.
Finally, I added all fields to band 0, removed the child bands and used direct binding to the respective property list. Although this works, it doesn't seem like the correct approach as it causes me to manage one big shape instead of smaller, more representative shapes. Also, it forces me to repeat columns when the same column of data needs a different header caption.
It seems like using a datamember should work. Can you offer any advice on how to troubleshoot the binding?
twinfrey said:the challenge is to reuse the grid for different search results, which have different fields. The initial bind works, but then i lose all columns for any subsequent binding.
I'm not sure I follow you. If each set of search results has different fields, then how can the grid NOT lose the columns? If you bind the grid to a data source that has a different set of columns, then it has to destroy the old columns and create new ones to match the new data structure.
Are you saying that you have the same number of fields and just want to substitute one column for another, even though the columns and different names and may be of different types? If that's the case, then there's no way the grid can do this for you. You would have to store the column positions and widths yourself. You won't be able to load a layout that is saved in a grid with one data source and load that layout into the grid when it's using a different data source where the columns keys and datatypes don't match up.
twinfrey said:I know if the data does not match the configuration it will clear the configuration, so I was trying to use data member to shape the result object to match the configuration of columns.
Okay, so I think what you are saying here is that you are binding the grid to an UltraDataSource with a sort've generic set of columns. So I am guessing that maybe all of your search results have the same number of fields and only vary on one or two of the field names/types?
Is that right?
twinfrey said:I was trying to bind to child bands using a data member so that the grid would have the respective columns for the shape of the result.
You lost me here with "bind the child bands". I'm not sure what that means. Bind the child bands of what? The grid? The UltraDataSource? You can't bind a child band individually. You can bind the grid to a data source with a hierarchy, but it will show the whole hierarchy and the child bands are created based on the data source.
I'm still not clear on what child bands you mean here and whether or not your search results are hierarchical or flat.
If you have a flat set of results and all of the results have the same number of columns, then one thing you could do is use the UltraDataSource as a sort've intermediary between the grid and the "real" data source. You would do this by using the virtual mode. Basically, you would set up a set of columns on the UltraDataSource that matches any of your search results. This assumes they all have the same number of columns and that you can determine a data type that will work for all possible results - so some of the columns in the UDS might be of type Object.
Then you handle events of the UDS to populate the data on-the-fly. There's a sample called "Virtual Mode Samples" under the UltraDataSource and also in the WinGrid Samples explorer which demonstrates this sort've loading-data-on-the-fly technique.
This was your data source structure never changes, only the data does.
correct wcf is irrelevant. i think interfaces are irrelevant as well, as we have done the plumbing to handle the binding manager and i have created the same results with and without interfaces.
the challenge is to reuse the grid for different search results, which have different fields. The initial bind works, but then i lose all columns for any subsequent binding. once you change the data source it blows away the original configuration. I know if the data does not match the configuration it will clear the configuration, so I was trying to use data member to shape the result object to match the configuration of columns. I was trying to bind to child bands using a data member so that the grid would have the respective columns for the shape of the result.
Hi,
I haven't had much experience with wcf, but I don't think that matters, anyway.
I've read your description of the problem a couple of times, now, and I'm afraid I am not following you.
Are your search results hierarchical? Or is it just a flat list of data?
If you are binding the grid to an UltraDataSource, then it probably doesn't make sense to apply a specific DataMember, since you would end up displaying only the children of a particular parent row - whatever the current parent row in the CurrencyManager would be.
I know that the DotNet BindingManager will not return proeprties that are exposed via an interface, it only exposes public properties. So I'm not surprised that Interfaces may be giving you trouble. But again, I'm not really clear on what you are trying to accomplish with this or even what the problem is.