I and other developers on my project have had numerous issues with losing all our columns settings on UltraGrids. It's become comical it happens so often. The column settings we lose are anything below the DisplayLayout->ColumnCollection. Column header captions, custom editor control settings, which columns from the data source are hidden, widths... etc.
All our grids are SingleBand and MaxBandDepth of 1 (because otherwise the dev environment will lock up as reciprocal references in the object graph seem to loop forever in UltraGrid. And the default Max Depth of 100 is insane. So if you don't remeber to set it to 1 and SingleBand only, you just lost whatever wasn't saved. Anyhow, atleast that issue has a workaground. Back to the more annoying problem...)
Our datasources are objects from an NetTiers entity layer. The collections types we're binding to are you standard MS example code for bindable data sources. They implement all the interfaces you would expect.
It's difficult to constantly reproduce this using the GUI editor (ultra designer). There appears to be some way where if you make sure: 1) You never hit the cancel button (cancel = reset all columns every time)2) Make sure every time you go into the Ultra Designer you break down the band and open up the column designerthen you have about an 80% chance of after hitting OK, all your columns not reverting to defaults (as if it just was attached to the datasource for the first time).
If i want to make this happen everytime the easiest way I've found is the following:
1.) Click on an UltraGrid bound to a collection source2.) Use the visual studio default Properties grid to navigate down DisplayLayout->Bands[0]->Columns: (Collection)3.) Click on the ellipsis to bring up the Column Collection editor4.) Hit Cancel and cry as every column reverts as if the whole band is being reset. This happens everytime. Sometimes you can open up the designer generated file and use 'undo' to restore what the cancel deleted/changed. Which is pretty silly. After all, the whole point of a cancel, especially when you've made no changes to the state, is to leave whatever it is you are messing with in the same state as when you started. Which seems a pretty simple thing to do when you don't even mess with the state. Atleast, it should be.
At the very least, if the cause of this massive headache is something complicated or part of .Net binding sources or Visual Studio or whatever, what I'd REALLY like to see is the following message box:
"WARNING! The changes you have made will cause the UltraGrid to recreate the column collection from the Data Source. Any column-specific metadata will be lost and reverted to default values. Are you REALLY SURE YOU WANT TO DO THIS DAVE?"
I wouldn't even make is a Yes/No box. because no-one is ever going to hit Yes. Just make it default to NO. If someone really wants to reset their columns they'll un-set and re-set the datasource property.
Hi Craig,
Oh, I see what you mean. generating code for the InitializeLayout method would be quite an undertaking. The code that gets serialized is generated in a different way then code you would write in the InitializeLayout event and it's not really compatible.
But I encourage you to Submit a feature request to Infragistics.
Hi Mike,
No, I knew about that. That just creates an XML file containing the settings in the DisplayLayout. What I suggested was to generate C# code that assigns the property settings in InitializeLayout.
Craig
Hi,
You can already do this. If you right-click on the grid at Design-time and select the Layout Wizard, you can save the grid's Layout to a file and then load that file back into the grid either at run-time or design time.
Actually, there is something you can do:
Add a function to generate the InitializeLayout code. Take any value in the DisplayLayout that isn't default and generate the code to recreate the setting.
Don't make it wipe out the existing InitializeLayout code, just put it on the clipboard or allow writing it out to a file.
Unfortunately, there's really not much we can do with something like this. This could be anything. It could be a corruption of the form, it could be something in the DataSource serialization code that is blowing up or unintentionally causing a reset. If we can't duplicate the issue, there's really no way to fix it or even determine if the problem is with the grid or something else.
Personally, since I am aware of how touchy the design environment can be when it comes to data binding, I tend to do as much as possible in the InitializeLayout event rather than the designer. Or, save the layout of the grid to a file as often as possible.