This is a follow-up on trouble catching the InvalidColumnKeyException. Another posting claims the behavior is "by design" but in my scenario it doesn't seem like a good design.
(Earlier post http://es.infragistics.com/community/forums/t/90920.aspx)
As near as I can tell, the XamGrid occasionally sends out the exception (Infragistics.Controls.Grids.InvalidColumnKeyException) to be thrown on the dispatcher at a later, more unpredictable time. This happens via a private method Infragistics.Controls.Grids.XamGrid.ThrowInvalidColumnKeyException(). The result is that the exception can't be easily handled. Appropriate exception handling might include rebuilding the list of XamGrid columns in a different way that would exclude the invalid key. Hopefully the eventual exclusion of the key would not leave the XamGrid in an unpredictable or inconsistent state.
So here is my scenario. I have a XamGrid which at one point in time used a bound column with a given Key but since that time the programming has changed so the underlying column data no longer exists. However, when deserializing a previously saved column layout (via PersistenceManager.Load), the obsolete column key is encountered, albeit briefly. But there is enough corner-case logic in place that the columns can be rejected, eventually replacing them with the new programming defaults . Indeed, it is easy enough to catch other exceptions that are thrown in PersistenceManager.Load such as InvalidPersistenceGroupException. That type of exception is well-behaved and doesn't get thrown via the dispatcher and so it allows corner-case logic to be executed.
Would you agree that it is not ideal for PersistenceManger.Load to crash the application by raising an exception on the dispatcher? Is there a way to change the behavior if the unbound key is encountered via the method "PersistenceManger.Load"? Is there a workaround I can use in the meantime?
Hi,
I did a brief research on this today and wasn't able to find a good reason for XamGrid to be throwing the exception asyncronously. I'm submitting a development issue about this so we could look at it in more detail and ultimatly getting rid of the async throwing of exception.
I'll provide more details about the development issue shortly.
Hi David,
I've create a case on your behalf with ID CAS-165100-H5D9T4. Your case is also linked to development issue 207784.
You can view the status of all development issues connected to this case from the "Development Issues" tab, when viewing this case on the "My Support Requests" page of our website.