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
Hi Rory,
roryap said: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.
Whenever the grid's DataSource or DataMember property is changed, or when the grid receives a reset notification from the data source, it has to decide what to do with the new data source.
It will try to maintain the layout if the new DataSource has the same data structure as the old one. So it checks the band and columns keys in the new data source and compares to the old one. If anything is different, it has to throw away the old layout in favor of the new data source's structure.
This will happen both at run-time and at design-time.
I can't see any reason why modifying one class in an assembly to affect grids that are bound to completely different class instances. The grid will not even know that anything happened in such a case, since it will not get a notification from the data source and it's own data source will not change.
Personally, I always like to set up any layout stuff for my grids in the InitializeLayout event at run-time. This way, there's never any chance that a designer hiccup of any kind will lose my layout. It's also good because there are some things that cannot be serialized by the layout, anyway, and will get lost when you change the DataSource at run-time. Interface properties like SortComparers are a good example.
Another thing you can do is use the Layout Wizard at design-time and save the grid layout to a file. That way, if anything happens, you can just load the layout back into the grid from that file.
Thanks for your reply, Mike.