mccamike said:

It seems that the UpdateRowBatch event is called once for each row in a WebGrid that is updated, instead of once for a "batch" of updated rows as its name suggests...

That's correct.

mccamike said:

how does this different from the UpdateRow event besides losing cursor focus of an updated row does not trigger a postback?

The difference is that, if you handle the UpdateRow event, the act of WebGrid changing active rows or losing focus causes the grid to trigger a postback - even if you don't put any code in the UpdateRow event handler.  If you're using UpdateRowBatch, the grid doesn't automatically trigger a postback.

This means that you don't need to manually "walk" through the grid rows.  You'll get one instance of UpdateRowBatch (or UpdateRow) for every row that was updated since the previous postback, and you'll get a reference to that row in the "e.Row" parameter.  (This includes rows that were added and modified since the last postback, so checking whether the row is "Added" or "Modified" may still be useful.)

There's one additional event you may want to use when using the grid's batch events:  UpdateGrid.  This event is raised once after all AddRow, UpdateRow, UpdateCell, and/or DeleteRow events (or their "batch" equivalents) are finished.  For instance, if you want to re-bind your grid to be certain that it reflects what's in your data source, you want to do this in UpdateGrid, since doing so in UpdateRowBatch could interfere with the update process.