Hi Mike, I find that this event will also be fired if a cell value is updated, whether the value is changed or not ((could be same value been assigned to the cell again). Is there a way to suppress the event in this kind of scenario or is there any other events can be used? Is there a kind of CellChange event when the data source cell data is udpated?

There's no way to suppress the InitializeRow event in that specific case. Why would you want to? If the value has not changed, then the code in InitializeRow will presumably not do anything. 

There is a CellChange event on the grid that fires when the user types or otherwise modifies the value in a cell.

There's no event in the grid for specifically when the data in the data source changes. It doesn't make sense for the grid to have an event for this - the data source presumably has it's own events to notify you when something has changed, so you don't need the grid to act as an intermediary. 

I am having a similiar problem.  I have a hierarchical grid and when I click a row (even if I'm not changing anything) random rows (I checked the data in e.Row) are being Initialized.   Sometimes not even the row I clicked on.  I have 189 rows with my sample and I can click a row and 5 random rows get initialized.

To make matters worse there is one set of sample data where it tries initializing "null" rows.   All of the data in the row is showing up as System.DbNull, however, nowhere in the DataSource or displayed in the grid is there a single null or DbNull value.  I'm using Infragistics v6.2 for a Windows app.

I don't know what's up with the "null" rows. That sounds like it may be a bug. 

But the other behavior you describe is correct. The rows will initialize when the grid thinks it needs to initialize. This may be because a value has changed or the row is scolled into view for the first time, or something in the data source changed. 

Why is this a problem for you? This event is intended to allow you to color a row or perform some other operation on a row based on values in that row. It's not an event that you should use to do processor-intensive or performance-intensive operations. 

The only actual problem with it I'm having is the "null" rows.   I simply put in a null check to make sure the values I'm checking aren't null to get around that, but I was mainly trying to figure out why the "null" rows were coming up to begin with.   I would rather not have the "null" rows than have to code a workaround into the code.