We are getting a random ThrowArgumentOutOfRangeException in our application. Looking at the call stack, it is being caused in OnBindingListChanged which originates in OnDelayedChange. It appears that in OnBindingListChanged it is attempting to access an element in “list” without verifying the element is there. Unfortunately, we are unable to re-create this outside of our application. Is this something you are aware of and will be making changes to correct? The full call stack at the time of the exception is:
at System.ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument argument, ExceptionResource resource) at SD.LLBLGen.Pro.ORMSupportClasses.EntityViewBase`1.GetEntityAtIndex(Int32 index) at SD.LLBLGen.Pro.ORMSupportClasses.EntityViewBase`1.System.Collections.IList.get_Item(Int32 index) at Infragistics.Windows.DataPresenter.RecordManager.OnBindingListChanged(Object sender, ListChangedEventArgs e) at Infragistics.Windows.DataPresenter.RecordManager.ProcessChangeNotification(Object sender, Object eventArgs) at Infragistics.Windows.DataPresenter.RecordManager.ProcessQueuedChangeNotifications(Boolean calledFromDelayedChange) at Infragistics.Windows.DataPresenter.RecordManager.OnDelayedChange()
ThanksDan
Hello Dan,
I have been investigating into the exception you are seeing in our forum and private support case history, and it appears that the last time an exception was reported for the XamDataGrid relating to OnBindingListChanged was back in 2016, and it was fixed in the versions that were receiving active development at that time, which were 2015.1, 2015.2, and 2016.1. As such, I have some questions for you on this matter. Can you please provide some information on the following?
1. What specific version of Infragistics for WPF are you using?
2. What is the user action that is triggering this exception?
3. Are there any multi-threading operations happening in your application when this exception occurs?
Please let me know if you have any other questions or concerns on this matter.
Thanks Andrew. Here are the answers to your questions
Thank you for confirming the multi-threaded operations, version, and user action.
Unfortunately, this isn’t really enough to go on to continue with a potential fix for this as we will need a reproducible scenario in order to do that. I am aware in your original description that you mentioned that you are unable to re-create this behavior outside of your full application, but we will need an isolated sample that reproduces the behavior in order to take action on it either created from your end or ours.
Since you had mentioned that this generally happens when a window is shut down, are you perhaps doing something in response to when the window closes? Perhaps in a handler for Unloaded or something of the like?