Can someone point me to a link which explains difference between IsPostBack, IsCallback and IsCrossPagePostBack in ASP.NET?
I have googled but didn’t get exact information.
Found below link for difference between IsPostBack, IsCallback.
What is the difference between Page.IsPostBack and Page.IsCallBack?
Thanks,
Balu
1) IsPostBack: "A postback is a request sent from a client to server from the same page, user is already working with." ASP.NET was introduced with a mechanism to post an HTTP POST request back to the same page. It’s basically posting a complete page back to server (i.e. sending all of its data) on same page. So, the whole page is refreshed.
2) IsCallBack: “A callback is generally a call for execution of a function after another function has completed.” But if we try to differentiate it from a postback then we can say: It’s a call made to the server to receive specific data instead of whole page refresh like a postback. In ASP.NET, its achieved using AJAX, that makes a call to server and updating a part of the page with specific data received.
3) IsCrossPagePostBack: “Gets a value indicating whether the page is involved in a cross-page postback or not." It's a different feature from "IsPostBack" and "IsCalBack" because It's generally used when we need to get the data from previous page
Reference Link
Related
i've been asked this question and id not know the answer.
Thanks for any help!
Postback is a term used often in ASP.NET when a WebForm POSTs the single form back to the server and invokes some event in the code behind (like a click on a button for example). You could still use normal GET requests though to redirect to a given web page. For example you could use an anchor:
Go to page 2
When the user clicks on the anchor there is no postback occuring but a GET request to the target web page.
Another possibility is the user typing directly the address of the web page in his browser address bar.
Yet another possibility is to use javascript to perform an AJAX request which allows to invoke a web page without redirecting away from the current page. You could use any HTTP verb with AJAX.
We can use javascript code to do some function without postback. This will save the time for the request and response to the server. But this client side. you can't reach the server without posting back.But my mean you can do functionality by javascript which does not postback the page.
Hope it may help.
If you like to categories the call to the server you can say that there are two types.
The GET and the POST
The POST is the post back and are the parameters that you send using a form
and the GET that are the parameters that you can send from the url.
More about:
http://www.cs.tut.fi/~jkorpela/forms/methods.html
http://thinkvitamin.com/code/the-definitive-guide-to-get-vs-post/
http://catcode.com/formguide/getpost.html
but I think the interview question was about the Ajax call, and this is probably what they try to see if you know, how to use Ajax to reach the server with javascript and not make postback. But you need to know that Ajax can make POST back, but this is done with out leave the page, with out make a full page post back.
I am a bit curious how ASP.Net internally identifies that the request is a postback.
I have read in a Microsoft book that you can technically do a postback using both POST and GET methods
This means that commands do not have anything to do with postback.
I have tried to use Fiddler to see what the request headers are sending. I am thinking that it could be something to do with the viewstate but I am not sure.
You're nearly right.
The correct event is fired based on the _EVENTTARGET and _EVENTARGUMENT variables which are sent as part of the request. I believe the IsPostBack is set based on the values of these. These determine which event to fire and with what arguments.
The actual submit is fired by the __doPostBack() function in javascript.
More detail here: http://dotnetslackers.com/Community/blogs/haissam/archive/2007/05/18/Which-Control-Caused-PostBack_2100_.aspx
I have a simple form that dynamically presents a data entry form, and the user does a postback and the results are saved to a database. I have created a new version of the form, and based on some information on a database, when the user requests the URL of the old form, I wanted to do a Server.Transfer to the new *.aspx page to generate the page and handle the postback. Since the URL of the page will not change, does that mean the postback gets sent to the original page? Would I then need to check if it's a postback, and if so then call Server.Transfer and allow the form data to be transfered to the new page?
It depends on what you mean by "gets" the postback. The first page will get the form values posted of course, since they are sent from the client. However, how far the first page gets through reacting to the postback information depends on when in the lifecycle you initiate the Server.Transfer. If it is extremely late in the lifecycle (like a click handler), then the first page will have pretty much gone through the entire postback process.
The optional parameter to preserve form values in Server.Transfer dictates whether the second page also reacts to the request as if it is a postback.
Take a look at the HTML source of the page after the Server.Transfer. If the form's action is the new ASPX then you are okay.
It would probably be easier to use a regular redirect. That way you don't have these kinds of issues.
I work on ASP.NET C#. Under button click event I want to save something it's work fine, but after press the refresh button of browser, this event occurs again I want to stop this event.
An article on this subject.
Preventing Duplicate Record Insertion on Page Refresh
Approach 1
A simple solution is to
Response.Redirect back to the same
page after the INSERT command is
called. This will call up the page
without transmitting any post headers
to it. Using Request.Url.ToString()
as the first parameter of
Response.Redirect will cause both the
URL and the page's querystring to be
included in the redirect. The use of
false as the second parameter will
suppress the automatic Response.End
that may otherwise generate a
ThreadAbortedException. A
disadvantage of this approach is that
any ViewState that had been built up
will be lost.
Approach 2
A related approach would be for the form to submit to an intermediate processing page and then Response.Redirect back to the calling page, similar to the classic ASP approach to form processing. This has the same effect as simply using the Response.Redirect in the Button_Click event so it has the same disadvantages, with the added disadvantage of creating another page for the website developer to manage.
Approach 3
The next batch of solutions works by
determining whether the user has
refreshed the page in the browser
instead of pressing the form's submit
button. All of these solutions depend
on the ability of the website to use
Session variables successfully. If
the website uses cookie-based
Sessions, but the user's browser does
not permit the use of cookies, these
solutions would all fail.
Additionally, should the Session
expire these solutions would also
fail.
Approach 4
Should the user somehow manage to
circumvent the above mentioned solutions described
above, the last line of defense is at
the database. There are two methods
that can be employed to prevent a
duplicate record from being inserted
into the database. For each method,
I've moved the SQL code into a stored
procedure, since there are now more
processing steps involved and these
are easier to illustrate in a separate
stored procedure. Note however that a
stored procedure is not strictly
required in order for these methods to
work.
Rather than using the Session object or storing to the database, I am storing temporary variables that I need persisted to custom ViewState variables. For example, ViewState("MyField1") = 1
When the user hits the browser Rrefresh button, Page.IsPostback is back to False and the ViewState is gone.
My question is. If the user can blow away the Viewstate by refreshing, why would anyone use it?
I know that a Refresh reposts the last submitted page, by why is Page.IsPostback reset to False and the ViewState blown away?
Flame me if you want for creating a potential dup question, but I've read other postings here, and it ain't sinking in...
Update to original post:
I now think that it has to do with postbacks that are performed as a result of clicking on Buttons that are within an UpdatePanel. Can someone help shed some light on this?
When a client refreshes their browser, it re-submits the last full page request issued by the client (which may be a GET or a POST). It does not ever resubmit AJAX requests such as those produced by update panel event triggers ("partial page postbacks").
The fact that Page.IsPostback is false when you refresh the page means that your original request is a GET, so here's what's probably happening:
1) During the initial request, the client sends no form data to the server - hence no hidden field containing view state data (Understanding ASP.NET View State is pretty detailed, but a great read if you want to really understand what's going on). While processing this request, ASP.NET may send some view state back to the client, but the original request is just a URL.
2) When the user clicks a button within an UpdatePanel, they trigger a partial postback during which MyField is set to 1. The UpdatePanel changes the client's view state to reflect the new value.
At this point, if the user submits a POST request by normal means, such as clicking a button, the view state will contain the updated information.
If the user clicks 'Refresh' though, they re-submit the original request from step 1, with no form data and therefore no view state.
Where do you set your ViewState? And where do you re-read your ViewState value? Maybe oyu check its content before asp.net calls the LoadViewState() method.
User hitting refresh and using updatepanel will not work together very well. I quess this is why people say that WebForms provides a leaky abstraction on web programming and some are moving to mvc.
If you're not interested in migrating, I'd give you the advice that do not use updatepanel for too long or big operations, where you can assume that user might refresh the page. Use it for small things like dropdown2 items changing when selection on dropdown1 changes.
Wrapping lots of functionality in one updatepanel will cause trouble, if you just depend on viewstate.
Your question is, "Why would anybody use it."
Viewstate comes in handy for data you know is generated by a post back. Hitting refresh is not a post back, but a fresh request.
So lets say you are browsing a datagrid and you need to know certain bits of data about what they have clicked, on the click event you could store that data in the viewstate and process it during other times in the page life cycle, or subsequent post backs.
ViewState's advantage is that it is just embedded into the HTML, so it is all client side. Where as SessionState is server side, and if you store a great amount of data in the session you can cause your web or db server to work harder to handle that data.
Hope this helps.
Don't know why it works but I had a similair problem and solved it by putting this line in the form_load:
me.myProperty = me.myProperty
where
Public Property myProperty() as String
Get
If Not IsNothing(ViewState("data")) Then
Return CType(ViewState("data"), String)
Else
Return String.Empty
End If
End Get
Set(value As String)
ViewState("data") = value
End Set