By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,024 Members | 1,945 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,024 IT Pros & Developers. It's quick & easy.

Which update button is clicked in FormView ItemUpdated event?

P: n/a
Hi

I have 2 update buttons in my FormView ('Apply' and 'OK'). I want both
buttons to update the data source but the 'OK' button should redirect
afterwards.

I can see which button is clicked in the ItemCommand event but I can't
redirect from here because the ItemUpdated event hasn't fired yet.

I can put a variable in the code-behind class which is gets the
CommandArgument in the
ItemCommand event and then read it in the ItemUpdated event but this doesn't
seem to
follow the event model concept very well. Is there a better or more
appropriate technique I could use?

Thanks
Andrew

Sep 22 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Hello Andrew,

Is the redirect here means redirect the current page to another page/url?
If so, what come to my mind first is use Page.ClientScript to dynamically
regisgter a clientscript to do the redirection at client-side. We can
register the scritp in the certain update button's update server event
handler. Since the client-side code will be executed after the page is
rendering to client, all the server-side code will be executed as normal.
How do you think of this?

And for client-side redirection, you can use

window.location.href = "new url"

to do the work.

Hope this helps.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.
Sep 22 '06 #2

P: n/a
Hi Steven

Thanks for the prompt reply. I'm not sure this will work for me as I may
wish to use Server.Transfer in the future. I have discovered a more alarming
problem with the Server-side redirect however:

The exception thrown in the ObjectDataSource Inserted event does not stop
the redirect in the FormView ItemInserted event. e.g.

protected void odsAccount_Inserted(object sender,
ObjectDataSourceStatusEventArgs e)
{
if (e.Exception != null)
{
throw e.Exception.InnerException;
}
}

// this still runs
protected void fvAccount_ItemInserted(object sender,
FormViewInsertedEventArgs e)
{
if (isRedirect) Response.Redirect(REDIRECT_PAGE);
}

I find this very odd. Can you explain this and let me know how I can get
around it?

Thanks again
Andrew
Sep 22 '06 #3

P: n/a
OK, I have to check for an exception in here too. Is there a could
explaination of handling exceptions in web controls?

protected void fvAccount_ItemInserted(object sender,
FormViewInsertedEventArgs e)
{
if (e.Exception == null)
{
if (isRedirect) Server.Transfer(REDIRECT_PAGE);
}
}

Thanks
Andrew
Sep 22 '06 #4

P: n/a
Hello Andrew,

Thanks for your quick reply.

Yes, if you'll use Server.Transfer (server-side redirection) later,
client-script approach won't work. For server-side redirection case, I
think you may consider set a flag (a page variable ) to indicate that
whether the request should be redirected and do the transfer/redirect in a
later event(such as Page_PreRender...).
And as for the new problem you mentioned:

====================
The exception thrown in the ObjectDataSource Inserted event does not stop
the redirect in the FormView ItemInserted event. e.g.

protected void odsAccount_Inserted(object sender,
ObjectDataSourceStatusEventArgs e)
{
if (e.Exception != null)
{
throw e.Exception.InnerException;
}
}

=======================

this is due to the internal exception handling codelogic of the FormView
and the underlying DataSourceView it calls(for your scenario, it's the
ObjectDataSourceView). As you've also found, the FormView.ItemInserted
event can help capture the exceptions occured during the insert operation
and expose it thourgh the event argument:

#FormView.ItemInserted Event
http://msdn2.microsoft.com/en-us/lib...trols.formview.
iteminserted.aspx

Of course, this is the particular implementation of FormView (and some
other template databound control), for some simple webcontrols, there won't
have such additional exception management code logic. Actually the
detailed code logic of the FormView's ItemInserting process is as below:

1) We use postback event to trigger the FormView's Insert or manually call
FormView.InsertItem programmtically

2) FormView call its internal "HandleInsert" method which call the
DataSourceView(obtain from datasource control)'s Insert method.
DatasourceView.Insert is an asynchornous method and FormView will pass an
callbackhandler.

3) and in DataSourceView.Insert method, there is a large try...catch....
block which will capture any exceptions and return it (without rethrow it
to the original control). The code logic is like:

4)The callbackhandler(in FormView) will construct a ItemInsertedArgument
and call the OnItemInserted method which trigger the ItemInseretd event.

#"callback" here is the callbackhandler passed in 2)
=======================
try
{
num1 = this.ExecuteInsert(values);
}
catch (Exception exception1)
{
flag1 = true;
if (!callback(num1, exception1))
{
throw;
}
return;
}
finally
{
if (!flag1)
{
callback(num1, null);
}
}
========================

Thus, you can see why you'll get the exception through the event argumenet
in the FormView.ItemInserted event. If you have interests, you can use the
reflector tool to inspect the diassembly code of the FormView and
DataSourceView for a clearer view.

If you have anything unclear above or anything else we can help, please
feel free to let me know.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.

Sep 25 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.