We're using UltraGrids quite extensively throughout our application. They're all bound to datasources and are used to view data only, the adding/editing goes on elsewhere.
Randomly (or what seems to be randomly) the grids will lose column settings (their hidden property and header caption) but the other properties will remain saved (autofitstyle/override properties etc.)
I've tried a number of things in the code in an attempt to stop this happening, like only setting the data source as the array if the array has data, using the SetDataBinding instead of DataSource, with and without the DataBind() method.
The same is happening with the UltraCombos.
Can anybody help please?
Thanks
Paul
Hi Paul,
That's quite a puzzle. The grid will throw away it's DisplayLayout under certain circumstances, like when the DataSource is changed or the DataSource sends a Reset notification to the grid.
But I've never heard of the grid losing some settings and not others. My best guess is that this is something in your code which is either resetting those properties specifically, or else the DisplayLayout is getting thrown out and your code is re-applying most, but not all, of the settings.
I would advise you to take a look at the InitializeLayout event of the grid. If you are handling this event, then it will get called any time the data source gets reset. So if your code is setting the properties that are NOT getting lost, that might explain why.
You might also want to search your code to see if you are ever calling the Load method(s) on the grid's DisplayLayout.
FYI, there is never any reason I've been able to find to call the DataBind method on the grid (or any Windows Forms control) since setting the DataSource or DataMember implcitly binds.
As a general rule, you should always use the SetDataBinding method and never explicitly set the DataSource or DataMember properties, and never call the DataBind method.
Mike,
Could you please expound on the circumstances under which the grid will throw away its DisplayLayout? I'm assuming you mean the design-time DisplayLayout is reset (which is what is happening to me) rather than a runtime reset.
I have a grid which is bound to a data source -- an object hierarchy -- that resides in a separate assembly we've built. Occasionally, I make changes to some elements of that object hierarchy, and sometimes I notice that the manually-configured grid DisplayLayout changes. I guess I'm OK with directly-associated changes occurring (e.g., if I add some new properties to a class, the grid row gets new columns added) -- although it would be nice to receive a notification instead of having it silently change on me -- but, I've also noticed other grids being affected as well, which shouldn't have been affected at all. For example, say I have 3 grids, each of which has a data source pointing to some different collection of objects within my DLL. If I make changes to the classes within the DLL which should only affect the grid that points to collection #1, I've noticed that Grids 2 and 3 also have their DisplayLayouts "messed up" (partially, like Paul said in his original post).
Ultimately, this represents hours of wasted time ferreting out and repairing messed up display layouts in what is a pretty extensive grid-based application. I'm not sure whether Paul's suggested fix will work for us, as I haven't tried it yet. But, is there any information you can pass my way to help mitigate this problem and explain the circumstances under which it happens? Your insight would be much appreciated.
-Rory