Hi,
2008 volume 3 UltraGrid.
An earlier thread detailed a problem with the VisiblePosition property on a grid column not updating when the column's visible position within a grid is changed. See the post "VisiblePosition of UltraWinGrid Columns Not Updating".
I have the same situation. I have some code to save and restore the grid layout that relies on the VisiblePosition property. The property doesn't seem to work so my code fails to lay the columns out correctly during deserialisation.
Here's some background:
I have an intialisation routine for the grid. The initialisation routine does all the usual things including setting up a summary block to appear at the bottom of the grid and specifying the format of the data to appear on a row when it is a group-by row.
My serialisation code merely iterated the list of columns and saved and restored some of the attributes within - Key, Hidden, Width, VisiblePosition, IsGroupByColumn & SortIndicator. There was no special code to save or restore the summary block or the group-by row information.
To overcome the problem with VisiblePosition, I've followed the advice in the earlier post and adapted my code to use UltraGrid.DisplayLayout.SaveToXml and UltraGrid.DisplayLayout.LoadFromXml. This solves the problem. Yipee! BUT - it introduces two other problems that weren't present in my original implementation.
1. Generally speaking, if a column is selected for 'group-by', the text on each of the expandable rows contains the name of the column followed by the column value, the number of items in the group and some other information controlled by the programmer (see the note regarding initialisation above).
E.g. "+Boundary : D173DEBLO (1 item) <other information>" where the Boundary column is a group-by column and D173DEBLO is one of the values for that column.
With my old serialisation code, this format was mantained across the save/restore.
Using the DisplayLayout Save/Load methods, the group-by settings are maintained but the group-by rows are now missing the additional information, e.g. "+Boundary : D173DEBLO (1 item)". <other information> is missing.
2. Underneath the rows for the whole grid with no group-by or underneath the child-rows for each group-by row I had arranged for summary information to be displayed. This summary information layout was maintained across my save/restore, but the summaries are missing following the DisplayLayout Save/Load.
I have verified that when re-loading a grid from Xml, the grid is first initialised and then the LoadFromXml method is called on the DisplayLayout member.
Is it expected behaviour that these two formatting setups are not saved and restored by the SaveToXml and LoadFromXml methods?I was expecting that the load and save methods on the DisplayLayout member would save and load the complete layout, not just certain parts of it.Can you offer any guidance as to what is considered 'best practice' regarding saving the layout of a grid and re-loading it later?
RegardsDavid Razzetti
jumpjet said: 1. Generally speaking, if a column is selected for 'group-by', the text on each of the expandable rows contains the name of the column followed by the column value, the number of items in the group and some other information controlled by the programmer (see the note regarding initialisation above). E.g. "+Boundary : D173DEBLO (1 item) <other information>" where the Boundary column is a group-by column and D173DEBLO is one of the values for that column. With my old serialisation code, this format was mantained across the save/restore. Using the DisplayLayout Save/Load methods, the group-by settings are maintained but the group-by rows are now missing the additional information, e.g. "+Boundary : D173DEBLO (1 item)". <other information> is missing.
What is the "<other information>" and where is it coming from?
The text of the GroupbyRows is determined by the GroupByRowDescriptionMask property. So perhaps you are setting this property in your code somewhere either before or after the saving and loading of the layout and it's somehow getting out of synch. This property setting should be saved as part of the layout, assuming you are passing in the correct flags to save grouping.
Another possible way to change the text of the GroupByRow is to use the InitializeGroupByRow event. So if you are handling that event, check to make sure you are not stepping on some other settings.
Still a third option is that the "other information" is a summary or multiple summaries. Perhaps you are not including summaries in your save or load method calls.
jumpjet said: 2. Underneath the rows for the whole grid with no group-by or underneath the child-rows for each group-by row I had arranged for summary information to be displayed. This summary information layout was maintained across my save/restore, but the summaries are missing following the DisplayLayout Save/Load. I have verified that when re-loading a grid from Xml, the grid is first initialised and then the LoadFromXml method is called on the DisplayLayout member. Is it expected behaviour that these two formatting setups are not saved and restored by the SaveToXml and LoadFromXml methods?I was expecting that the load and save methods on the DisplayLayout member would save and load the complete layout, not just certain parts of it.Can you offer any guidance as to what is considered 'best practice' regarding saving the layout of a grid and re-loading it later?
It's starting to sounds like your loading or saving of the layout simply does not include the summaries and that this is the information that is missing from the GroupByRows. The only way that should happen is if you are passing in flags to the Save or Load methods and excluding the summary information.
Hi Mike,
2008 volume 3
Thanks for the reply.
With respect to the restoration of the summary information, I have done some more invetigative work and can report the following:
I'm using the overload of SaveAsXml that takes a PropertyCategories argument and I'm specifying PropertyCategories.All.
The SummarySettingsCollection element within the XML produced by the SaveAsXml method is always empty. My code is using custom summaries. The custom summary class is marked as serializable.
If I temporarily replace the custom summaries with summaries taken from the built-in types (e.g. Count), the SummarySettingsCollection element within the XML is populated as expected.
Is it expected behaviour that the SaveAsXml method fails to save summary information that uses custom summaries? If the method should cope with custom summaries, is there anything special that I need to do to facilitate the save?
Regards
David Razzetti
Hi David,
What exactly do you mean by a "custom summary" in this case? What class are you using and what is it derived from? Is this a class that derives from FilterCondition?
It seems like it should work, if that's what you are doing. The FilterCondition class is Serializable and ISerializable. So perhaps you need to implement the ISerializable interface on your derived class as well as marking it [Serializable].
Hi Mike.
Ah ha! The custom filter classes being used do NOT inherit from FilterCondition. They are 'stand-alone' classes that merely implement the ICustomSummaryCalculator interface. I'll go away and look at deriving them from the FilterCondition class.
You don't HAVE to use a FilterCondition. I just wasn't sure what you meant by custom summary, exactly.
I just took a look and it appears that the grid is not attempting to serialized the CustomSummaryCalculator. This looks like a bug to me. If the instance is serializable, then it should be saved, I think.
I'm going to forward this post over to Infragistics Developer Support so they can write it up and get it looked at and hopefully fixed.
We are using the 14.1 Infragistics Version and we are facing the same problem.We have a case where we are displaying three summaries. One summary is a default summary (count) and three are custom summaries.By saving the layout
and then reloading it
the three custom summaries disappear.
What can we do?
Best regardsIsidor S.
When you say a "custom summary", does that mean you are using a CustomSummaryCalculator?
The grid probably can't serialize your CustomSummaryCalculator into the file. I'm not sure if it actually tries to do so, but if it does, it would only work if the class implemented ISerializable. If not, then check the Summaries collection on the band and see if the summaries are actually there after the load. If so, you just need to re-attach the CustomSummaryCalculactor to the summary. If they are not there, you will need to re-create them.