I have a datagrid with two template columns that have text boxes rather than labels to allow users to enter data for multiple items. The datagrid is bound to a dataset. I am also overriding the ItemDataBound for the grid to add extra rows that act as "headers" for grouping the data. There is one save button that loops through the datagrid and saves all the information at one time. This is not a problem.

My dilemma is what to do when an error occurs while saving the data. After catching the error, if I don't bind the datagrid, then the "headers" are either lost (if I add them dynamically in ItemDataBound) or replaced by empty text boxes (if I add them to the dataset and just change their appearance in ItemDataBound) -- since the ItemDataBound never fires. If I do bind the grid, then the text boxes use the values stored in the database (or no value at all) since they are bound again rather than any changes that the user has made. This can be bad when someone changes 20 or more rows and then loses the changes because they typed something wrong in just one box.

I know that I could develop my own text box control or my own custom datagrid column that stores the value before trying to save and restores it when an error occurs. I'm just wondering if there is a better way of doing this. Has anyone else had the same dilemma?

Adding extra rows is not really the issue -- when any type of manipulation is done to the datagrid in ItemDataBound and the datagrid also includes "user editable data" this problem could occur.

There is an important distinction between two events on the datagrid:

ItemDataBound and ItemCreated

As you have found, ItemDataBound fires when the item is databound (imagine that).

The ItemCreated event is fired every time an item is created for the grid. This means that it's fired when the grid is databound (rows generated) AND when the grid is reconstructed from ViewState. Another important note: the viewstate contains the data that was bound to the grid, but not the layout and such of the grid. Every time the page is executed, the grid is constructed from the data (whether it's new, i.e. when you call DataBind() or when it's from ViewState such as during a postback that doesn't involve changes to the grid data source).

SO... if you move the code that generates/modifies your custom grouping headers from ItemDataBound into ItemCreated you'll regenerate the custom layout without the need to rebind and thus loose the entered/changed data.

http://msdn.microsoft.com/library/en...eatedtopic.asp

-Peter

I have used ItemCreated before when changing the appearance of rows, and that does work, but I have a special case that might not work. I added extra rows to my dataset (through the stored procedure) that serve as the header rows by grouping my data as aggregates. Each one of these rows has a value of 0 for one of the ID fields that lets me know that it is a header row and not really a true data row.

Currently with the ItemDataBound event, I can get that value from e.Item.Cells(fieldx), test it for a zero, and act appropriately by either changing the row into a header or by leaving it alone and letting the data binding create the text boxes. When I try this within the ItemCreated event, I always get a blank string for the value of the cell!

Is there another way to differentiate between the rows in the dataset while in the ItemCreated event handler?

Aha. I see where the problem lies now. This was an oversight on my part. I have done a lot with tweaking the output of a datagrid so perhaps I replied too fast. I found (as did you) that the ItemCreated event doesn't have the contents of the grid when it's restored. First all you get are empty rows with the control structure defined by the <columns> node in the grid markup so this obviously won't work. Later on in page execution you'll find that the cell contents are restored (but not quite to the exact structure you customized to). So I did a little testing to see where you can make the modifications you need and I think I found a solution.

When you bind the data, the row will contain your initial data. Then you modify it to your specially constructed row structure. After the grid is completely restored you'll have a similar state of the rows as you left them, but not perfectly so. What I found was that you can put a loop later in page execution (page prerender works for me) that spins thru all the rows of your grid and does what you need to do. The one catch is that you need to leave some unchanged column with the data you want to check to trigger the custom row changes. For this you can create an additional column in the grid (I'd recommend it be the first column) and leave that column not visible. It will still exist as the first column (and subsequently the first cell in the e.Item.Cells collection) so you can always refer to it despite the fact that it is not rendered to the final HTML table output. Then it just becomes a matter of checking for that trigger information (the 0 ID data in your case).

In the course of testing I created this sample that should give you what you need:

http://www.geekdork.com/samples/Twea...ridOutput.aspx

Click on the "How it works" link at the top right and you can see all the source markup and code-behind for the sample.

-Peter