Category Archives: Infragistics

WHDG: Give Grouped columns correct captions

If you work with Infragistics WebHierarchicalDataGrid and try to use its grouping features, you may notice that it uses grid column keys instead of column header’s captions to name items in “Group By” area.

To work around this limitation, let’s take a look at how Grouped By area is rendered:

Group By Area in WebHierarchicalDataGrid

Basically a container DIV holds a bunch of SPANs representing grouped columns. Both DIV and SPAN can be located by their CSS class (your own, if it’s assigned or Infragistics StyleSet class name, used by the grid control). Knowing the location of the SPANs we can loop thru them altering their text:

function renameColumnsInGroupByArea() {

   //locating GroupBy area DIV 
   var oGroupArea = document.getElementsByClassName('ighg_IGGroupArea')[0]; 

   //locating GroupedColumn SPANs
   var aGroupedColumns = oGroupArea.getElementsByClassName('ighg_IGGroupedColumn');

   // looping thru SPANS with grouped columns, replacing their text
   for (var I = 0; I < aGroupedColumns.length; I++) {
      aGroupedColumns[I].firstChild.nodeValue = // put your new value here;
   }
}

One way of using this function is generate a JavaScript associative array (ColumnData['ColumnKey'] = 'Column Caption') in ASP.NET server side code. Armed with such array Line 11 in the previous code could be simple

aGroupedColumns[I].firstChild.nodeValue = ColumnData[aGroupedColumns[I].firstChild.nodeValue]

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):

Public Enum GRID_AJAX_CALL_TYPE
   NON_AJAX = 0
   PAGING = 1
   SORTING = 2
   FILTERING = 3
   CHILD_POPULATING = 4
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

      Return GRID_AJAX_CALL_TYPE.NON_AJAX
   Else
      Return GRID_AJAX_CALL_TYPE.NON_AJAX
   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
   '...
Else
   If GetGridAjaxCallType() = GRID_AJAX_CALL_TYPE.CHILD_POPULATING Then
      RebindTheGrid()
   End If
End if

Solution: WebDataGrid loses styles after postback

Infragistics WebDataGrid control offers very flexible styling option – you can set font, color, size of almost any element from column to individual cell. Here is an example of basic markup that sets CSS classes of overall grid control, grid header, grid odd row and grid even row:

<ig:WebDataGrid ID="xMyGrid" runat="server"
   CssClass = "GridStyle"
   HeaderCaptionCssClass = "GridHeaderCellStyle"
   ItemCssClass = "GridCellStyle"
   AltItemCssClass = "GridAltCellStyle" 
>

And corresponding example of CSS class for even row:

tbody > tr.GridAltCellStyle > td
{
   font-size:11px;
   font-weight:normal;
   font-family:Verdana, Geneva, sans-serif;
   height:20px;
   padding: 2px 2px 2px 2px;
   border-bottom: none;
   border-right: 1px solid rgb(190,198,178);
   background-color:rgb(240,240,240);
}

(For a complete grid styling reference take a look at this styling guide)

And it all works fine, your grid renders so beautifully, Picasso would cry. But only on initial page load. And here comes dreadful postback. Continue reading →

UltraWebGrid strange behavior in IE8 when IE=EmulateIE7

If you’re using Infragistics UltraWebGrid in Internet Explorer 8 you may experience strange visual (and other) issues if you have page compatibility set to emulate IE7, e.g.

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

Issues can range from column moving not working to weird distortion in grouped mode. According to Infragistics this combination is not supported as “unstable”, but you can still make it work.

Infragistics keeps internal flags of what browser is currently in use: ig_shared.IsIE7, ig_shared.IsIE8, etc. The trick is to detect IE8 and make it fall back to IE7:

if (ig_shared.IsIE8) {
    ig_shared.IsIE8 = false;
    ig_shared.IsIE7Compat = true;
}

Place this code on top of your page JavaScript code and when it sees IE8 it will tell grid to use IE7 rendering. This is most definitely a hack, but it works.

UltraWebGrid: “Input string was not in a correct format” error while setting width of a column

Infragistics UltraWebGrid allows you to set width of a column in client-side JavaScript, you can do it using code similar to this:

igtbl_getGridById('xmyGrid').Bands[0].Columns[3].setWidth(someValue)

But, while executing this code on the client, you may get a nasty surprise by getting following error from the server:

Input string was not in a correct format.
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.FormatException: Input string was not in a correct format.

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:

[FormatException: Input string was not in a correct format.]
System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal) +10163939
System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info) +207
Infragistics.WebUI.UltraWebGrid.StateChangeProcessor.ProcessChanges() +6230
Infragistics.WebUI.UltraWebGrid.UltraWebGrid.ProcessChanges(StateChanges stateChanges, Boolean fireEvents) +701
Infragistics.WebUI.UltraWebGrid.UltraWebGrid.LoadPostData(String postDataKey, NameValueCollection values) +7580
System.Web.UI.Page.ProcessPostData(NameValueCollection postData, Boolean fBeforeLoad) +945
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +2071

Now, you do know that your someValue is definitely a number, why this error then? Let alone – why client-size resize causes a server call? But I will leave this to Infragistics. Actual cause of the error – number not being Integer. If you change the code from above to

igtbl_getGridById('xmyGrid').Bands[0].Columns[3].setWidth(Math.ceil(someValue))

it will execute without any errors. Go figure.

UltraWebGridExcelExporter: Export more than 65536 rows

When exporting data from Infragistics UltraWebGrid into Excel using UltraWebGridExcelExporter ordinary a very basic code similar to this is used:

'
' define Exporter "xMyExporter"
' define UltraWebGrid "xMyGrid" and load grid with data, then:
'
xMyExporter.ExportMode = UltraWebGrid.ExcelExport.ExportMode.Download
xMyExporter.Export(xMyGrid)

That’s it. But, if your data exceed 65536 rows you will get an error:

System.InvalidOperationException: The maximum number of rows in an excel worksheet with the current format is: 65536

This is not Excel Exporter limitation. Continue reading →

‘this.Column.Band’ is null or not an object error in UltraWebGrid filtering

When you filter Infragistics UltraWebGrid by clicking Filter icon in the column header – dropdown with filter values appears. Normally if you click elsewhere on the page – dropdown disappears. But sometimes it doesn’t, for example if you click an element that invokes a JavaScript function. Filter dropdown stays open and this could cause problems – when grid refreshes (and possibly other actions are performed) error is thrown:

‘this.Column.Band’ is null or not an object

The solution to this is to close filter dropdown ourselves. Put these lines into your client-side code whenever clicking outside the filter doesn’t close it:

var aGridCols = igtbl_getGridById('xMyGrid').Bands[0].Columns
   for (var I = 0; I < aGridCols.length; I++)
      aGridCols[I].showFilterDropDown(false);

Here we’re looping thru grids column collection (This example assumes grid is in Flat or OutlookGroupBy mode, if your grid is hierarchical, you will have to loop thru band collection as well). For every column we pass False to showFilterDropDown method which (probably showing Infragistics cute sense of humor) hides filter dropdown if it is open. If dropdown is hidden for the column already – nothing happens.

As a result opened filter dropdown is now always closed prior to previously offending action and the error doesn’t happen.

Speed up UltraWebGrid rendering on rebind

If you’re using Infragistics UltraWebGrid with it’s property Browser="Xml", you may find yourself living in a shotgun shack in a strange situation: When grid is rebinding – it takes (comparatively) short time to do server-side processing and then a very long time to render grid in the browser.

In my case it was most felt when grid (which had ViewType="OutlookGroupBy") was initially grouped with a lot of data in each group and then ungrouped back into flat view when user dragged last group column out. Using IE9 built-in developer tools I ran JavaScript profiler I found that culprit was Infragistics JS function “disposeNode” which was called numerous times and had worst both inclusive and exclusive execution time. Continue reading →

WHDG: Correctly detect Async Callback

When using Infragistics WebHierarchicalDataGrid often there’s a need to detect grid’s async callback (for example we need to rebind the grid if it performs AJAX paging or expanding children). For flat WebDataGrid it was suggested to use grid’s RunBot.IsCallback property:

If xMyGrid.RunBot.IsCallback Then
   'Perform some operations for grid's async callback
End If

Now, WHDG also has RunBot.IsCallback property, but the above code always returns False for it. I know I’ve seen this before – a situation where a property doesn’t work on WHDG control itself, but works on the WHDG’s GridView object. Sensing a pattern I modified the code above for WHDG:

If xMyGrid.GridView.RunBot.IsCallback Then
   'Perform some operations for grid's async callback
End If

And bingo! Now Async callback is detected correctly.

UPDATE 4/27/2012: Turned out the above method doesn’t always work either. (To Infragistics stuff, if anybody happened to read this: The scenario above happens with WHDG in manual load on demand mode when grid’s RowIslandPopulating event is handled and ContainerGrid is created on demand and bound to data retrieved from the Database). The above method works when rows of the top level expanded (xMyGrid.GridView.RunBot.IsCallback is True) but fails if child rows are expanded to show grandchildren (in that case xMyGrid.GridView.RunBot.IsCallback is False).

We need another more reliable way to detect callback, no matter what caused it. And we can do that by checking HTTP Request. If it’s an Infragistics callback it will have a Form parameter with key like "__IGCallback************". So the code to always detect the callback correctly is:

If Request.Form.AllKeys.Any(Function(S As String) S IsNot Nothing AndAlso S.StartsWith("__IGCallback")) Then
   'Perform some operations for grid's async callback
End If

WebDataTree returns multiple selected nodes in single-select mode

This could be a bug in Infragistics WebDataTree control or it could be a very specific scenario (maybe it’s even by design, I don’t know) but here’s a weird behavior that I encountered. Using following code in WebDataTree’s event handler (oh and by the way, tree control is in a single-select mode):

Protected Sub xMyTree_SelectionChanged(ByVal sender As Object, ByVal e As NavigationControls.DataTreeSelectionEventArgs) Handles MyTree.SelectionChanged
   if e.NewSelectedNodes(0).Text = "Some Value"
      'do something with newly selected tree node
   end if
End Sub

I intended to use newly selected node to perform some operations. To my surprise e.NewSelectedNodes(0) referred to previously selected node (despite the name of the property) and newly selected value were located in e.NewSelectedNodes(1)! So the quick workaround was to use slightly modified code:

Protected Sub xMyTree_SelectionChanged(ByVal sender As Object, ByVal e As NavigationControls.DataTreeSelectionEventArgs) Handles MyTree.SelectionChanged
   if e.NewSelectedNodes(e.NewSelectedNodes.Count-1).Text = "Some Value"
      'do something with newly selected tree node
   end if
End Sub

This way it will always get latest selected node and the solution is universal. If the bug described above occurs – code will grab e.NewSelectedNodes(1) (because Count = 2). If the tree behaves as expected – code will get grab e.NewSelectedNodes(0) (because Count = 1)