I'm designing a gridview-based UI that I would like to behave like this (this is in a context roughly like that of a structured e-discussion):

After the user selects a record, and then specifies an action from a menu item:

==> another record (identified by an algorithm which uses the ID of the first record), becomes "updatable", with the cursor positioned in it's "main text" field (and the "main text" field is in a template in a column).

I'm just starting to experiment with gridview, and I can see there is a feature to place an update button on each row, through which each row can become independently updatable. Perhaps the feature that I describe above could be implemented through the methods and events associated with the "built-in" update feature in gridview. However, I would prefer to do this without placing an update button on the row (to keep the user from updating anything else, and not use up the line space), and without requiring the user to press the update button and move the cursor to the "main text" field.

Also, I don't yet see the techniques in Web Forms for making a particular field "active" (and how that might work using templates fields in gridview.)

Any guidance on where and how to research techniques for and build this feature would be appreciated.

Thanks!

By default, only one row in the GridView can be updateable. You can replace the default Edit button in the Grid with a custom control, like this:

<asp:ButtonField CommandName="Edit" Text="Edit Me" />

The trick here is the CommandName property that sets the Grid in Edit mode for the selected row.

Alternatively, you can set the EditIndex programmatically. You can add a button to the page and then add the following code in its Click event:

Protected Sub Button1_Click(ByVal sender As Object, _
     ByVal e As System.EventArgs) Handles Button1.Click
GridView1.EditIndex = 2
End Sub

This sets the third row in the Grid as editable. Where and how you call this code depends on your application. But, you still need to find out what row the user wants to edit.

To prevent users from updating some of the fields in the row, set the ReadOnly attribute to True:

<asp:BoundField DataField="FirstName" HeaderText="FirstName"
ReadOnly="True" SortExpression="FirstName" />

Does this help?

Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.

Thanks for your input. I've found that I've set my design ambitions too high, relative to my current programming abilities...I'm going to first implement something that's more like a detail view + gridview, and come back and convert to the more "exotic" UI later. The business logic will be the same, and that's where I need to work for now (partly to keep the energy for the project up -- my own!). "I'll be back". Thanks!

Imar: I've made a little more progress...

The main context for this post is, within a gridview:

user: Select row
System: insert blank row below selected row
user: edit new blank row
user: press button to request row be updated
system: update row to datasource

Hopefully, this will be done without roundtripping the page. It appears that Gridview internals are limited to SQL commands, which can only insert at the end of the datatable (or other source)...although, if I use an objectdatasource, I might be able to do a "smart" insert...but it would still require a refresh from the server...and Gridview doesn't have a built in insert...

So, the current approach is to use javascript to find the selected row, and to use javascript to add a row directly to the HTML, and then do some kind of callback to update the datasource. The table will look right, and will be synchronized with the datasource...it will just be a kludge that steps around gridview, temporarily, between page refreshes.

Going back to the question of making the row editable...the approach outlined above would side step "editability" from Gridview's perspective. That one row would be constructed in the html to look and behave like any other gridview row, while in the browser. And it would "originate" in "edit" mode, immediately after a previous select on it's "parent" record...and that select would not have been possible if any other "real" edits were in progress.

So maybe the remaining question is how important is it to update the gridview keys collections, in order to maintain sorting and paging, between page refreshes (if that's what they're for---newbie-blank---)...or will any sort and page commands cause a datasource refresh anyway (thus rebuilding the whole html table, and throwing away the "inserted row")?

Any thoughts on this...particularly the value of updating the keys collection in this scenario, at the time the datasource callback update occurs?

To have your newly inserted row survive post backs, you'll have to insert it in the data source anyhow. Otherwise, whenever you do a server side sort or paging operation, the row is gone.

So, I don't think you have to worry about DataKeyNames for the data source, because at any stage, all rows in the source (and Grid) have a DataKey or you're currently inserting one row through client side JavaScript.

When you add your own row to the Grid through JavaScript, you'll need to write a custom handler for the update button's click that retrieves the values from the (dynamically) inserted form control. In that case, you can no longer use .NET controls (like txtFirstName.Text) but you'll have to resort to the Request.Forms collection.

Is there any reason why a FormView or DetailsView is not an option? Also, why is a round-trip "Add new Row" button not acceptable?

Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.

Thanks for your message, and the feedback about the approach I proposed. That clears the way for me to use it (particularly knowing I don't have to be concerned about the datakeys). With respect to why use this approach, it's really a matter of refinement in the UI. Perhaps you remember the early spreadsheet programs, where you had to go to a little data entry window in order to update a cell. And this was a requirement in MS Project 98, which was then improved to allow "in place" updates in MS Project 200x. So I think it's clear that the "in place" updates is a more advanced UI. Likewise, "in place" inserts are a more advanced UI. In the app I'm working on, the user is building a structured list, in which the position of the insertion has specific meaning relative to the other records. Allowing the user to do an insert in place reduces the interruption and distraction caused by having to go to a separate sub-form, and allows the user to maintain greater focus on the content of the list. It's a small difference in terms of the system ending up with the information, but a meaningful difference in terms of user attention...that most precious of resources!

At any rate, this thread has been very helpful because I'm ready to bite the bullet on using javascript as the third-level refinement of the user experience, knowing it's the only real alternative.

Thanks again for the help!