Is there anywhere I can go to get some elaboration on the behavior of the XamGrid in conjunction with your Persistence Framework?
Reading the code for myself would be the best. Short of that, some form of reader's digest version may help me.
My understanding is that the Persistence Framework is generally based on a "brute force" dumping of all serializable properties in the memory of the object(S) selected. There is also some support for filtering those properties by their names (and/or "paths"). However I've found that the XamGrid also uses some "smarts" to pick between a couple different variations of this persistence strategy.
In some cases during a load operation, the XamGrid reuses the existing columns (ColumnBase) and their instances remain the same in memory, despite a Persistence Framework deserialization (load) operation. In other scenarios the load operation uses a different strategy (I call it the "slam-dunk" approach) whereby it *clears* *out* the old column instances and rebuilds an entire collection of new columns from scratch, replacing the old ones. I'd like to know,
In particular the "slam-dunk" approach is no good and we don't have any use for it. The approach destroys all data templates and styles (well-documented) and involves too much work to rebuild these things. I'd only use the Persistence Framework's deserialization (load) if it could be done *without* the "slam-dunk" approach. Otherwise the user would need to start over and reconfigure the grid from the programmer's default.
Please help. Hopefully I'm on the right track in my understanding of the strategies for deserializing the xamGrid. It took many hours and much trial-and-error to get this far.
Andrew, Thanks again for your help.
The CanRehydrate is a good tip. Is there a way to get the Persistence Framework to get to that point (comparing keys) and go no further? IE. instead it would return to me only the information about whether or not it intends to "rehydrate" (use the existing columns)? My problem is that I currently have to go all the way thru the Load and I have a pretty bad hack (basically an event handler on Columns.CollectionChanged.Reset) that tells me what happened so that, after the fact, I can manually reverse out all of the disastrous work that the Persistence Framework did.
Thanks, David
PS
Here is a link about the removal of all styles, data templates, etc. There is something called a "persistence identifier" that is supposed to come to play but it sounds more trouble than its worth (ie. I'd sooner lose the user's datagrid customizations than have to use this approach.)
http://help.infragistics.com/Help/Doc/WPF/2014.1/CLR4.0/html/Persistence_Identifier.html
Hello dbeavon,
Thank you for your post!
You are correct in that there are essentially two methods of the persistence manager loading the columns collection of the XamGrid. The criteria that determines which of these methods is chosen is based upon the protected IProvidedPersistenceLookupKeys.CanRehydrate method implementation of the ColumnBaseCollection of that XamGrid. This is checked when loading the column collection, the persistence manager will compare its lookup keys against the keys of the columns in the XamGrid.Columns collection. If the keys match exactly or are in a different order, then the CanRehydrate method will return true and it will use the pre-existing columns. The opposite is that the lookup keys do not exactly match the column keys. This will have the CanRehydrate method return false, and it will recreate the columns of the XamGrid.Columns collection.
One thing I wouldn't expect is that if the columns collection gets recreated due to the CanRehydrate method returning false, that the pre-existing, saved column styles and templates would get removed as well. However, after testing this with a sample project that I have created, it appears that this is indeed the case.
This appears to be unexpected behavior, and as such, I have asked our engineering staff to examine this further. To ensure that this issue receives attention, I have logged this issue in our internal tracking system with a development ID of 207767. I have also created you a case so that you can track the status of this development issue. This case has an ID of CAS-165073-Q7V3S7 and you can access it at https://ko.infragistics.com/my-account/support-activity.
Please let me know if you have any other questions or concerns on this matter.
Sincerely,AndrewAssociate DeveloperInfragistics Inc.www.infragistics.com/support