Hi there
I have a problem with Ultragrid whereby it's losing the column layouts I set at design-time when the app is run. I'm getting this in several places in my app and it seems to occur at random, the grids are working fine, then they just lose their settings, even when that part of the app hasn't been worked on.
I've had a good read through what's been posted previously on this, and I understand that this is probably due to the runtime datasource not matching what was set at design-time. I can't really understand how this would be the case as the full column list displayed at design-time matches up the columns shown at runtime.
My questions are;
E.g.
Parent object is a CustomerClass, and CustomerClass has a child collection of CustomerClass.OrdersList.
The form is bound to the CustomerBindingSource, which has a datasource of CustomerClass
the grid on the form is bound to a OrdersBindingSource, which has a datasource of CustomerClass and a datamember of "OrdersList".
Any help in getting to the bottom of this would be much appreciated, it is driving me nuts!
tom_redox said:How do I check that this is the case - i.e. what's the bet way to debug this. I take it the grid doesn't throw an exception to say the datasource didn't match up with the layout?
There's no way to trap for this. But if there were, I'm not sure I see how that would help.
tom_redox said:What are the possible causes of this - how does the grid decide whether the datasource has changed? Is it just looking for matching field names and datatypes or is there more to it than that?
I don't think the grid looks at the data types of the field. It looks at the columns (number of columns and the keys of the columns) and also the bands (number and keys). The most common problem I encounter is that people get the keys of the bands wrong. The key isn't always what you think it is. For example, when using a DataSet, the key of the child band is the name of the relationship, not the child table.
tom_redox said:What's the best practice for setting up the bindingsources for grids? Currently I have a bindingsource for the form which has a child list property that is displayed in the grid. The grid is bound to a second bindingsouce which has its datasource set the form's datasource and the datamember set to the child list property. At runtime all I do is then set the parent bindingsource's datasource to an instance of the class. Does that sound right?
I'm not sure I follow you there. If you want to set up the layout of the grid at design-time, then there are really two ways to do it:
Personally, I have found that the BindingManager in DotNet is a bit quirky and sometimes sends reset notifications at unexpected times. So I prefer to set up my layouts at run-time in the InitializeLayout event of the grid. That way, there is never any chance of losing it.
Another way to do it is to set up the layout at design-time and save it using the layout wizard. You can store the layout to a file or into the grid's Layouts collection, then load it at run-time.
Hi Mike
Thanks for your detailed response. I should have made it clearer in my initial message that the grid is bound to a collection object (specifically a csla collection implementing all the MS binding interfaces).
Mike Saltzman"] There's no way to trap for this. But if there were, I'm not sure I see how that would help.
My thinking was that it would be easier to find the issue if the grid threw a message along the lines of "Key "CustomerID was not found, grid layout reset" - this would then give me a start on working out where the problem lay.
Mike Saltzman"] I don't think the grid looks at the data types of the field. It looks at the columns (number of columns and the keys of the columns) and also the bands (number and keys). The most common problem I encounter is that people get the keys of the bands wrong. The key isn't always what you think it is. For example, when using a DataSet, the key of the child band is the name of the relationship, not the child table.
That's interesting to know. Our grids are based on custom collection classes, how do the keys for the bands work for these?
A couple of other question on this, do keys need to be unique for columns across bands. E.g. if the Customer (Band 0) has a Date Entered field and so does the child OrdersList collection (Band 1), would that cause an issue?
Also, we use the System.ComponentModel DisplayName attribute on our classes to set a friendly name for each property of the class. This is then used by the grid to set the column headings. Do these values play any role when assessing whether the runtime and designtime schemas match and are duplicates in these column headings an issue?
Mike Saltzman"] Personally, I have found that the BindingManager in DotNet is a bit quirky and sometimes sends reset notifications at unexpected times. So I prefer to set up my layouts at run-time in the InitializeLayout event of the grid. That way, there is never any chance of losing it.
Ouch.. so effectively that means setting the key, column header text plus any formatting, plus any custom editors and the displaystyle etc for every column manually in code?
I guess I could cut and paste this from the auto-generated designer code after the first setup of the grid?