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.
It would be nice if someone from Infragistics could respond to this issue. It is extremely annoying to lose all your settings.
Thanks in advance.
It's not just the column settings. It appears to be any settings and it doesn't seem to matter which control it is. I have seen this problem appear numerous times over the last year or so. Different computers, different versions of VS, different versions of the controls. It doesn't matter. I have seen numerous reports here but never a proper response.
Typically, if the grid loses it's formatting, it's because the data source sent a Reset notification. The grid tries to maintain the layout settings whenever it can, but if something in the data source changes that causes the current layout to be incompatible with the data source, then the grid has to discard the layout in favor or the new data structure.
If you are doing something to the data source that is basically innocuous, and you don't think it should be causing the grid to lose the layout, then Infragistics Developer Support will be happy to look into it and evaluate it as a possible bug and try to get it fixed.
So if you can duplicate this behavior, you should Submit an incident to Infragistics Developer Support.
Well, there's really not much we can do without being able to reproduce the issue. I mean, even if we fixed it, how would we know? [:)]
What I recommend in a case like this is that you use the Layout Wizard in the grid designer to save your layout to a file periodically, so that if the layout is lost, you can re-load it from the file.
If you can reproduce the problem, then you should definately Submit an incident to Infragistics Developer Support.
THat's just theproblem, I don't believe it's a problem with code, it's something environmental going on after a point. For example, the project I ave now has been going on for quite a few months and is somewhat big. Just this weekend I began experiencing this problem. If I shut down VS, I stil l have the problem but if I re-boot, sometimes it goes away briefly.
I'm not sure how to repro that.
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.