469,160 Members | 1,877 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,160 developers. It's quick & easy.

Preventing DataBind in a FormView

I'm at a loss here...
My FormView control automatically performs a databind at each postback on
the server. But in some cases I don't want this to happen. Like when the
business layer decides that some of the information in the controls cannot be
accepted. But then the FormView binds to the datasource again, and the input
in all contols is lost. And the user will have to type it all over again.

In ASP.NET 1.1 we could simply say: If Not Page.IsPostBack Then DataBind()
And the ViewState would take care of the rest.

How can I do this in ASP.NET 2.0?
Mar 30 '06 #1
5 1951
IT works in the same way.

"Jurgen Appelo" wrote:
I'm at a loss here...
My FormView control automatically performs a databind at each postback on
the server. But in some cases I don't want this to happen. Like when the
business layer decides that some of the information in the controls cannot be
accepted. But then the FormView binds to the datasource again, and the input
in all contols is lost. And the user will have to type it all over again.

In ASP.NET 1.1 we could simply say: If Not Page.IsPostBack Then DataBind()
And the ViewState would take care of the rest.

How can I do this in ASP.NET 2.0?

Mar 30 '06 #2
No it does not work in the same way, otherwise MS wouldn't have introduced
those brand new data source controls.

Databinding with FormView is done implicitly. There is no explicit DataBind
instruction. The FormView takes care of the binding itself.

I tried intervening with various events. But this only led to the entire
FormView being broken.

IT works in the same way.

"Jurgen Appelo" wrote:
I'm at a loss here...
My FormView control automatically performs a databind at each postback on
the server. But in some cases I don't want this to happen. Like when the
business layer decides that some of the information in the controls cannot be
accepted. But then the FormView binds to the datasource again, and the input
in all contols is lost. And the user will have to type it all over again.

In ASP.NET 1.1 we could simply say: If Not Page.IsPostBack Then DataBind()
And the ViewState would take care of the rest.

How can I do this in ASP.NET 2.0?

Mar 30 '06 #3
OK i see what you mean, when you said "FormView control automatically
performs a databind at each postback" i presumed you meant that you had
written code to do that, apologies for misunderstanding.

It also takes care of the viewstate automatically, but there are certain
things that cause it to databind again. For example if you write to the
headertext property for a templateField, it seems to re databind and lose the
viewstate.

You can still do everything the ASP.net 1.1 way and not use the data source
controlls at all.

Alternatively you could try and work out what is causing the FormView to
re-databind everytime there is a postback, it definately does not do this
under most circumstances and the viewstate is maintained.

For example i have a page using a DetailsView control bound to an
SQLDataSource, in one of the TemplateFields there are two Drop down lists,
when you change the first drop down list it causes a postback and the
contents of the second drop down list are updated. When this happens
viewstate is maintained.

However if i have command in the OnSelectedIndexChanged event handler for
the drop down list , that updates the headertext on one of the
TemplateFields, the DetailsView re databinds and the viewstate is lost.

If you post your code i coudl try and spot what causing it.
"Jurgen Appelo" wrote:
No it does not work in the same way, otherwise MS wouldn't have introduced
those brand new data source controls.

Databinding with FormView is done implicitly. There is no explicit DataBind
instruction. The FormView takes care of the binding itself.

I tried intervening with various events. But this only led to the entire
FormView being broken.

IT works in the same way.

"Jurgen Appelo" wrote:
I'm at a loss here...
My FormView control automatically performs a databind at each postback on
the server. But in some cases I don't want this to happen. Like when the
business layer decides that some of the information in the controls cannot be
accepted. But then the FormView binds to the datasource again, and the input
in all contols is lost. And the user will have to type it all over again.

In ASP.NET 1.1 we could simply say: If Not Page.IsPostBack Then DataBind()
And the ViewState would take care of the rest.

How can I do this in ASP.NET 2.0?

Mar 30 '06 #4
If you design your update method (with the BLL) to return a bool (indicating
a success or failure) then you can subscribe to the ObjectDataSource.Updated
event to decide whether to turn cancel the FormView.ModeChanging or not, like
this:

private bool CancelEdit=false;
void ObjectDataSource1_Updated(object sender,
ObjectDataSourceStatusEventArgs e)
{
if (Convert.ToBoolean(e.ReturnValue)) CancelEdit=true;
}
void FormView1_ModeChanging(object sender, FormViewModeEventArgs e)
{
e.Cancel = Cancel.Edit;
}

--
HTH,
Phillip Williams
http://www.societopia.net
http://www.webswapp.com
"Jurgen Appelo" wrote:
I'm at a loss here...
My FormView control automatically performs a databind at each postback on
the server. But in some cases I don't want this to happen. Like when the
business layer decides that some of the information in the controls cannot be
accepted. But then the FormView binds to the datasource again, and the input
in all contols is lost. And the user will have to type it all over again.

In ASP.NET 1.1 we could simply say: If Not Page.IsPostBack Then DataBind()
And the ViewState would take care of the rest.

How can I do this in ASP.NET 2.0?

Mar 30 '06 #5
This is a correction to the typos in my previous post:

If you design your update method (within the BLL) to return a bool
(indicating a success or failure) then you can subscribe to the
ObjectDataSource.Updated event to decide whether to cancel changing the mode
while handling the FormView.ModeChanging event or not, like this:

private bool CancelEdit=false;
void ObjectDataSource1_Updated(object sender,
ObjectDataSourceStatusEventArgs e)
{
if (!Convert.ToBoolean(e.ReturnValue)) CancelEdit=true;
}
void FormView1_ModeChanging(object sender, FormViewModeEventArgs e)
{
e.Cancel = CancelEdit;
}

--
HTH,
Phillip Williams
http://www.societopia.net
http://www.webswapp.com
"Phillip Williams" wrote:
If you design your update method (with the BLL) to return a bool (indicating
a success or failure) then you can subscribe to the ObjectDataSource.Updated
event to decide whether to turn cancel the FormView.ModeChanging or not, like
this:

private bool CancelEdit=false;
void ObjectDataSource1_Updated(object sender,
ObjectDataSourceStatusEventArgs e)
{
if (Convert.ToBoolean(e.ReturnValue)) CancelEdit=true;
}
void FormView1_ModeChanging(object sender, FormViewModeEventArgs e)
{
e.Cancel = Cancel.Edit;
}

--
HTH,
Phillip Williams
http://www.societopia.net
http://www.webswapp.com
"Jurgen Appelo" wrote:
I'm at a loss here...
My FormView control automatically performs a databind at each postback on
the server. But in some cases I don't want this to happen. Like when the
business layer decides that some of the information in the controls cannot be
accepted. But then the FormView binds to the datasource again, and the input
in all contols is lost. And the user will have to type it all over again.

In ASP.NET 1.1 we could simply say: If Not Page.IsPostBack Then DataBind()
And the ViewState would take care of the rest.

How can I do this in ASP.NET 2.0?

Mar 30 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Daves | last post: by
5 posts views Thread by mosscliffe | last post: by
5 posts views Thread by J055 | last post: by
3 posts views Thread by =?Utf-8?B?cm9kY2hhcg==?= | last post: by
1 post views Thread by CARIGAR | last post: by
1 post views Thread by Mortomer39 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.