Hoping you'll have some suggestions for me; I've exhausted about everything I can think of hunting for a workaround. Perhaps you've seen something like this before and can suggest something I haven't thought of.
We're using a grid bound to an IBindingList. It's working great, except for one annoying bug (or unexpected behavior) which seems to be in grid code rather than in our code.
Our column resize is AutoFit. In general, this also works great - but one particular column has its size increased from 28 to 120, and another column which should be larger than the first has its column width reduced. There are four fixed-width columns in the row. There are three other non-fixed width columns which look like they have maintained the correct widths relative to each other.
I've done a lot of breakpointing and watching and stepping in my code, and confirmed by looking at the column collection itself that all the columns have the expected width after my code configures them. Sometime after I run a query which updates the bound list, and before any of my own code is triggered again, the columns change size as described.
Can you tell me any settings or behaviors which might cause the grid to do this internally?
Thanks in advance!
Hi Jon,
It sounds to me like something about processing your query is causing your data source to send a Reset notificaiton to the grid, which then blows away all of the columns and the data structure and creates all new ones with default widths.
So why don't you set the widths of the columns AFTER the query is processed?
A really good place to set column widths and positions is the InitializeLayout event of the grid. This event will fire any time the grid gets a reset notification or is bound to a data source, so it ensures that the layout is applied after the data source is established.
Also, why are you saving the colmun widths yourself. There are Save and Load methods on the grid's DisplayLayout that will do this for you.
When our control is loaded, we initialize a column dictionary which has in it all the properties of all the columns we will display. Farther down in the initialization process, after the grid has been bound to the IBindingList so that the bands and columns are established, we iterate through the column dictionary, configuring the columns in the grid based on the dictionary settings. This includes width, visibility and position for each column. After this happens, all the settings in grid's column collection in the band look exactly correct - including all widths for all columns.
Later in the startup process, a query is performed to populate the list we are bound to, updating the list and thus the contents of the bound grid.
I have literally breakpointed every public method in our control to confirm that, after the query completes, and until the column is shown with an incorrect width, none of our code runs - which is why I mentioned unexpected grid behavior or a bug in grid column sizing.
The column happens to be a date column, and it is using culture settings to customize the string display. I have tried turning off the culture formatting, though - same problem. I have also changed column order to see if that is a factor - it is not.
I know this is little detail about a complicated problem - but this is my problem debugging it, too. I have not tried to duplicate the problem in a small sample yet, but agree I may have to, if I've run out of other options.
There's really not enough information here to go on.
What are the circumstances where the column is changing size? Which column is it? What exactly is your code doing when you say "all the columns have the expected width after my code configures them". What event are you configuring them in?
Can you duplicate the problem in a small sample?
I should mention that I have tried turning AutoFit off, and when I do, the columns maintain their correct widths. It's only with AutoFit on that this happens, and the odd thing is that it's only two out of of nine columns that are unexpectedly resized.