As the Logical vs. Visual Grid Structure help article states, RadGridView for WinForms uses virtualization for its cells/rows and as of Q2 2010 there is column virtualization as well. What is virtualization? To put it simply, when you bind RadGridView to a DataTable with 1000 rows, you get 1000 data row objects created in RadGridView (of type GridViewDataRowInfo). However, not all data row objects can be visible at the same time in the RadGridView estate in your application. This is why only the visual rows that can be shown in the estate get created (these visual rows are of type GridDataRowElement), or about 20-30 rows for an average application with medium sized RadGridView. These visual rows are reused during scrolling, filtering and other operations with the grid, meaning dramatically improved performance and memory footprint as we create only a small number of visual items, rather than all of them. This is virtualization, and it works in similar manner for columns.
This approach has a few implications, namely not every data cell/row has a respective CellElement/RowElement at a given moment (note: CellElement and RowElement are no longer available in Q2 2010, the explanation for which you can find below). For example take the following picture:
When we scroll up, it may seem like the rows/cells are going down. But this is not the case. These rows cells are not moving, they are just being reused. So, if you can take the cell element containing “05033” while this data is in view:
this.radGridView1.Rows.Cells["PostalCode"].CellElement.DrawFill = true;
this.radGridView1.Rows.Cells["PostalCode"].CellElement.BackColor = Color.Red;
In the next moment when RadGridView is scrolled up/down the CellElement of the data cell will return null, since there is no CellElement associated with the data cell.
Considering this information, the following code snippet will produce an error:
for (int i = 0; i < this.radGridView1.Rows.Count; i++)
for (int j = 0; j < this.radGridView1.Rows[i].Cells.Count; j++)
this.radGridView1.Rows[i].Cells[j].CellElement.BackColor = Color.Red;
Even the following code snippet will produce an exception, because there is no guarantee that the CurrentRow will be in view when the snippet is executed:
this.radGridView1.CurrentRow.Cells["FirstName"].CellElement.Font = new Font("Arial", 12f, FontStyle.Strikeout);
Even though you have a scenario where CellElement/RowElement properties are used and this scenario works fine for the moment, there could be a case where there will be no CellElement/RowElement when you need it.
Because of these cases and many more that confuses our users, we decided to remove the CellElement/RowElement properties in Q2 2010.
If you want to customize the appearance of the visual cells/rows there are several much more elegant and efficient ways to do that: Formatting events
If you take a look at the RadGridView forum section, you will notice that usually all Telerik responses concerning custom visual scenarios suggest that you should use CellFormatting/ViewCellFormatting/RowFormatting/ViewRowFormatting. Getting the CellElement/RowElement from the arguments of these events guarantees that you will not end up with NullReferenceException, because of a missing element. Simply ,a formatting event is fired for a given cell/row when this cell/row needs to get its appearance changed. For additional information about these events, refer to the following documentation articles:
The Style property is a new addition to the RadGridView features. It was introduced in Q2 2010 and it is just one of the many improvements that we introduced in this version. For additional information, refer to the following blog post:
Another great feature of RadGridView. It allows for setting custom colors to cells/rows depending on the data of these cells/rows. For additional information, refer to the following support resources: