How do I write code for INSERT or UPDATE events of FormView control

[fr2]

Select a particular row in gridview .. brings up a formview to display detail for that selected row.

Instead of using the default INSERT and UPDATE links .. I have a funtion that needs the values in the formview textboxes .. to pass to a stored procedure which runs in a transaction.

1. How do I grab the values from the formview textboxes?

2. Which formview events do I code manually for the INSERT and UPDATE links

 

[jmeckley]

use the Inserting & Updating Events. the arguments passed to these events should contain the data you need. something like
e.OldValues and e.NewValues.

if those properties are empty the use TextBox box = (TextBox)MyFormView.FindControls("NameOfControl");
and extract the properties manually.

Since your not using the declarative syntax anyway, why not drop the form altogether and just use server controls?

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[fr2]

No I need to use the formview because of being able to toggle going into INSERT or going into EDIT mode ... the issue is once the mode changes .. and I then want to do an INSERT or do an UPDATE after the user enters info.. I want it to use my built in function or code instead.

Which FormView Event or how do I associate the default FormView INSERT or EDIT link button with my code instead?

 

[jmeckley]

use the formview inserting and updating events. for more information read the msdn help on formview.

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[fr2]

OK .. I kept the datasource and used only the SELECT command ... I took out the insert and update commands since I am writing the code maually for those.

I used the formview inserting and updating events .. and it did the inserting for me .. but AFTER that I get an error

Inserting is not supported by data source 'dsManageEventUserEventRole' unless InsertCommand is specified.

If I write my onw code for the inserting does that mean I CANNOT use the datasource at all .. not even just using the SELECT command ..

 

[jmeckley]

if use use a datasourceid the select/insert/update is wired automatically. if you manually bind.
GridView.DataSource = IEnumerable;
GridView.DataBind();
and you want to insert a record. you need to assign handlers to the gridviewrowinserting events. if you want to do post processing after these events you should use gridviewrowinserted. the same is true for update/delete.

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[fr2]

Cool was able to manually bind!

... Now I am having trouble getting the changemode .. to work. I got the insert to work ... now I dont know how to get the EDIT mode to bring up my edit template ... and what events to use to toggle between INSERT and EDIT modes? ...

I get this error when trying to save the viewstate to be able to bring up the edit template ... I wish there is sample UNBOUND formview code to look at.

How do I test for insert button click, and also EDIT button click, to go into each mode. I am having trouble bringing up the edit item template ...

Failed to load viewstate. The control tree into which viewstate is being loaded must match the control tree that was used to save viewstate during the previous request. For example, when adding controls dynamically, the controls added during a post-back must match the type and position of the controls added during the initial request

 

[jmeckley]

Failed to load viewstate. The control tree into which viewstate is being loaded must match the control tree that was used to save viewstate during the previous request. For example, when adding controls dynamically, the controls added during a post-back must match the type and position of the controls added during the initial request

this is specific to webforms and request validation. basically when a request is made the webform framework validates that the data it's receiving is the same/similar to a response that sent previously. if you have client code which modifies the dom before posting back, this will cause validation to fail.
2 options. 1. find the problem and fix it. 2. disable viewstate validation.

as for the detailsview. my recommendation is to not use them. gridviews are nice for sorting and paging tabular data. but for single record edits you're best to create the page manually without the concepts of "edit/insert" mode.

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[fr2]

Well the toggling of the EDIT/INSERT mode is what I really like about the FORMVIEW. For data entry I think its cool for what am working on.

In bound mode, I got it working ... but I generally do not like bound controls. I feel like as tables grow .. its performance diminishes .. and generally unbound has better performance.

Having said that I will be glad to learn to make the FORMVIEW work in unbound mode, .. if not .. I guess I would just have to use the bound to sqldatasource for now!

 

[jbenson001]

You don't need to bind to the sqldatasource controls for the formview. You can use a datatable. I suggest you don't use the datasource controls.

 

[jmeckley]

bound vs unbound is not what degrades performance. that happens because of 1. poor sql queries 2. large respones (usually viewstate)

if you use drag/drop objects like formview/[X]DataSource then all the data is stored in viewstate, but only the current record is displayed to the user. if you have a table with 3 columns and 10 rows this isn't too big of an issue. but if you have a table with 20 columns and 100 rows you will notice a lag.

for each server control dropped onto the page you can expect viewstate to increase. the fewer server controls (or disabling viewstate altogether) will drastically reduce page size.

the toggling of the EDIT/INSERT mode is what I really like about the FORMVIEW.

this is a dangerous and slippery slope. if you depend too heavily on m$ drag/drop controls you won't be able to mature as a developer.

think of the hours you have spend so far trying to get this to work. you like the control, but it's costing alot of development time. So what is to like about it?

the server controls (or raw html) don't take that long to write. You have more control over the final output. And you can resolve bugs much easier through debugging, unit tests and SoC.

Jason Meckley
Programmer
Specialty Bakers, Inc.