Tag Archives: ajax

Solution for WebHierarchicalDataGrid’s “Async request failed” error

This is a solution for specific (and maybe somewhat obscure, but it helped me, so perhaps it will be helpful to someone else) scenario for Infragistics’ WebHierarchicalDataGrid error “Async request failed“.

It could be accompanied by inner errors

Failed to load viewstate. The control tree into which viewstate is being loaded must match the control tree that was used to save viewstate during the previous request

or more generic

Object Reference not set

In this particular scenario WHDG uses manual LoadOnDemand for to populate children (i.e. RowIslandPopulating event is used) and parent grid is sorted by one or more columns. Error is happening when attempting to expand second child or a grandchild. Continue reading →

Infragistics: Detect type of AJAX callback

This post continues topic started in “WHDG: Correctly detect Async Callback“. Back then I described a way to correctly detect server-side when an infragistics control (WebHierarchicalDataGrid) issues an async callback.

But what if you need to detect actual type of the call and distinguish paging from sorting from filtering from row expanding? Well, where there is will there is way. Infragistics says there’s no build-in flag indicating AJAX action, but we can determine the action by intercepting and interpreting HTTP Request object.

First let’s define a return type in form of an Enum describing all possible outcomes (it’s always good to work strongly typed values):

   NON_AJAX = 0
   PAGING = 1
   SORTING = 2
End Enum

And now actual function. In the previous post I described that presence of AJAX call can be determined if key starting with "__IGCallback" is present in Request.Form collection. By interpreting actual value of Request item with that key we can determine type of AJAX call. For example, when grid’s row is expanding during load-on-demand, it contains JSON data "eventName":"Populating","type":"loadOnDemand" so our function simple has to catch it:

Function GetGridAjaxCallType() As GRID_AJAX_CALL_TYPE
   Dim sIgCallBackKey As String = HttpContext.Current.Request.Form.AllKeys.SingleOrDefault(Function(S As String) S IsNot Nothing AndAlso S.StartsWith("__IGCallback"))
   Dim sIgCallBackRequest As String

   If sIgCallBackKey <> "" Then
      sIgCallBackRequest = HttpContext.Current.Request.Form(sIgCallBackKey)

      'Detecting Child Populating.
      If sIgCallBackRequest.Contains("""eventName"":""Populating"",""type"":""loadOnDemand""") Then Return GRID_AJAX_CALL_TYPE.CHILD_POPULATING

   End If

End Function

The function tries to locate "__IGCallback" key in HTTP request (Line 2), if the key present – function reads actual Request value (Line 6) and if Load-on-demand populating is detected (Line 9) – returns result saying so, otherwise returned result indicated non-ajax call.

This example implements only one detection – Load-on-demand populating, I will leave it to you to add sorting/filtering/paging detection. Once implemented – usage is pretty straightforward:

If Not IsPostBack Then
   End If
End if

Solution for “Operation is not valid due to the current state of the object” error

Typically this happens when AJAX controls are involved (Microsoft’s UpdatePanel or others that utilize AJAX POST requests.) The error may be displayed outright or, if nothing is shown on the UI – logged in the Event Viewer. In any case you will get a message similar to:

0x800a139e – Microsoft JScript runtime error: Sys.WebForms.PageRequestManagerServerErrorException: Operation is not valid due to the current state of the object

Issue happens because Microsoft Security Update MS11-100 limits number of keys in Forms collection during HTTP POST request. To alleviate this problem you need to increase that number.

This can be done in your application Web.Config in the <appSettings> section (create the section directly under <configuration> if it doesn’t exist). Add 2 lines similar to the lines below to the section:

<add key="aspnet:MaxHttpCollectionKeys" value="2000" /">
<add key="aspnet:MaxJsonDeserializerMembers" value="2000" /">

The above example set the limit to 2000 keys. This will lift the limitation and the error should go away.