I'm using an UltraWinGrid that's bound to a IList of AccountRecords. I diligently laid out the Grid in the designer and hid many fields, but later had to go back and add another property to the AccountRecord class. When I ran the app again, every single item in the AccountRecords was visible, and the editor appeared to believe I had not bound to a DataSource.
At first I wrote it off as "one of those things", but when I did the same to my QuoteRecord the same thing happened to the two grids that used it.
This is very annoying. Is there any way to avoid this?
Maury
Hi Maury,
I'm not really sure I understand what you mean. It sounds like your grid is losing the layout. This will happen any time the DataSource sends a Reset notification to the grid.
There may be a way to get around this, but it's hard to say without more information to go on. For instance, are you modifying your data source at design-time or run-time?
You might want to check out this KB article, also: HOWTO:How can I define columns in the grid at Design-time and bind them at run-time so that some fields of the data are excluded from the grid?
Mike Saltzman"] I'm not really sure I understand what you mean. It sounds like your grid is losing the layout. This will happen any time the DataSource sends a Reset notification to the grid.
Yes, the layout is being lost. However, all I am doing to cause this is change an object in a completely different part of the solution.
For instance, I had a Grid of Users, which had FirstName, LastName and PhoneNumber. I laid out a grid with just the first and last names and everything was working fine. Then I went to the User class and added MiddleInitial, and when you open the Grid again all four fields are visible - PhoneNumber re-appeared.
Additionally, the Grid designer appears to believe that there is no DataSource bound it it, forgetting the source I had before. I can reset this easily enough, but why is it forgetting just by changing an underlying object?
Maury Markowitz said:Yes, the layout is being lost. However, all I am doing to cause this is change an object in a completely different part of the solution.
I'm not sure I understand you. You say "a completely different part of the solution". But the grid is bound to a list of users. So it's not completely different, there is a pretty clear and direct connection between the user object and grid in this case, no?
If you are losing the layout in this case, then adding a new property to the User object must be sending a reset notification to the grid. How is it that your User object exists at design-time, anyway? Is it part of a control or a component or something?
Normally, if the grid was bound to a data source at design-time, such as a DataTable, then adding a field is simply a matter of adding an item to a collection. The DataTable knows to send a notification that a new field was added.
But if you have a class defined in code and you modify that code, there's no way for it to send a notification that a field has changed. I'm not really sure how DotNet handles this kind of thing. But it's not like you have simply added an item to a collection, you have changed the signature of the object that the grid was bound to. It can't send a notification in this case. My guess is that Visual Studio just recreates a new object or something like that.
Maury Markowitz said:Additionally, the Grid designer appears to believe that there is no DataSource bound it it, forgetting the source I had before. I can reset this easily enough, but why is it forgetting just by changing an underlying object?
What do you mean by "appears to beleive?" Are you saying that the DataSource of the grid is still set and the grid is not recognizing it? Or that the property is actually being reset to null.
It would not surprise me at all if the DataSource we getting reset to null, since like I said, you are essentially creating a whole new object, as opposed to just modifying an existing data source. The instance of the collection that the grid was bound to most likely no longer exists and a completely new object is created.
If that's the case, then there's nothing the grid can do about this. But you might want to save the grid's layout to a file or into the Layouts collection. At least that way, you can restore the layout when something like this happens again.
A better solution, in my opinion, would be to set up the layout inside the InitializeLayout event in code, rather than at design-time. Then there is no chance of losing it.
Mike Saltzman"]If you are losing the layout in this case, then adding a new property to the User object must be sending a reset notification to the grid. How is it that your User object exists at design-time, anyway? Is it part of a control or a component or something?.
But I'm not doing this at runtime, I'm doing it at compile time. I am seeing this behavior:
1) create Entity object with two fields
2) make a RecordBindingSource that uses that Entity
3) bind that RecordBindingSource to the grid
4) lay out the grid to hide one of the columns
5) add another field to the Entiry
- now when the app is run, ALL of the fields are visible again.
Mike Saltzman"]What do you mean by "appears to beleive?" Are you saying that the DataSource of the grid is still set and the grid is not recognizing it? Or that the property is actually being reset to null.
I don't know, but here is what happens:
1) set up the Data Schema for a grid by importing from a RecordBindingSource and then customizing it.
-- if you open the designer again after saving, the designer "knows" there is a Data Schema, and there are Band and Column Settings.
2) make a change that causes the "reset" I am seeing above
3) when you use the designer now, the Data Schema appears to be null, and there are no Band and Column settings.
In some cases I have managed to get them to reappear simply by opening the designer, making some minor changes, Apply-ing and then opening it over again. It APPEARS that something is interfering with the loading process of the designer when it is in this state, and minor changes to the Designer.cs file corrects it (not all the time though).