Its so strange that just when you begin to feel like that you know a framework or toolkit in-depth, something from the same pops-up to surprise you and force you to rethink. I recently had a similar situation with the Ext.Net toolkit, that I have been using for approximately 3 years now, and feel pretty comfortable with.
When I began with the toolkit, I used Ext.Net controls as regular ASP.NET controls, relying on Postbacks to submit data to the server, until I discovered that the real power of the toolkit lies in submitting data to the server through asynchronous Ajax requests to Web Services (or Http Handlers). So, for sometime, all applications I have built with Ext.Net have been completely free of postbacks, until recently, where I needed to re-engineer an existing application and had to resort to postbacks for maintaining compatibility.
It should not have been too difficult in any case. However, for some reason, I got an IndexOutOfRangeException sometimes data was posted back to the server. Because the issue showed up only sometimes, it made itself that much more difficult to eradicate. Moreover, the issue never cropped-up in my testing, and only showed in front of the testing team. The details (Message and StackTrace, available below) the testing team provided only compounded the mystery around the issue:
Index was outside the bounds of the array. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.IndexOutOfRangeException: Index was outside the bounds of the array. Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. Stack Trace: [IndexOutOfRangeException: Index was outside the bounds of the array.] Ext.Net.MultiSelect.LoadPostData(String postDataKey, NameValueCollection postCollection) +897 Ext.Net.Field.System.Web.UI.IPostBackDataHandler.LoadPostData(String postDataKey, NameValueCollection postCollection) +13 System.Web.UI.Page.ProcessPostData(NameValueCollection postData, Boolean fBeforeLoad) +693 System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1743
One thing clear from the StackTrace was that the issue related to some MultiSelect on the page (and there were atleast 4-5 of them on the page). The Trace above provided no idea as to which one of them was causing the issue.
The Items in the Fields were added dynamically, so my initial instinct was that for some MultiSelect, the items were not added back properly on PostBack before the ViewState was restored, which caused the IndexOutOfRangeException when restoring the selected values from the client.
However, on very careful inspection, this possibility was eliminated as the original Items were added back to the MultiSelect properly in the Init event itself. After a long series of testing trials with different data, I was finally able to pinpoint the issue.
Remember, there’s a property called Delimiter on MultiSelect, which is used as a separator for the multiple items selected while concatenating them and which defaults to a comma (‘,’).
The data we added dynamically sometimes had comma in some item added to the MultiSelect. Now, when that item was selected and data submitted to the server, the toolkit was not able to figure out the correct places where to split submitted items that were concatenated on the delimiter.
Let me explain with an example. Suppose, the Items added to the MultiSelect are as follows:
Item 1 Item 2 Item 3, with comma Item 4
If you select any combination of Items to the server not including Item 3 (let’s say Item 1 & Item 2), it gets submitted to the server as (Item 1,Item 2),and the toolkit parses this concatenated submitted value to individual items by splitting it on the delimiter.
However, if Item 3 is selected with let’s say Item 1, it gets submitted to the server as (Item 1,Item 3, with comma). then on the server, the toolkit parses these into 3 values, and when trying to restore the selected values from the list of items, generates the said IndexOutOfRangeException, because obviously there are no Items corresponding to (Item 3 and with comma) separately and they get parsed out as separate selected items on the delimiter.
So, the solution is to ensure that the Delimiter does not appear in any of the list items for your MultiSelect, or else that would trigger exception when submitted if any of the selected item itself contains the delimiter. In my case, I changed the Delimiter to ‘%’, as the List Items were department names and can never have contained a percent symbol.
I believe the same applies to MultiCombo too, and you need to be careful of the same aspect for Delimiter property of MultiCombo also.
Recent Comments