Your Privacy Matters: We use our own and third-party cookies to improve your experience on our website. By continuing to use the website we understand that you accept their use. Cookie Policy
2150
WPF XamGrid and Persistence Framework Strategy
posted

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,

  • ("A") what the conditions are for using one strategy over the other,
  • and ("B") if there is a uniform/formal way to detect when one strategy is used over the other.

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.

Parents
  • 34810
    Offline posted

    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://es.infragistics.com/my-account/support-activity.

    Please let me know if you have any other questions or concerns on this matter.

    Sincerely,
    Andrew
    Associate Developer
    Infragistics Inc.
    www.infragistics.com/support

Reply Children
No Data