is there any way out to detect the full postback is occurred or partial postback occur when we work with PageMethod. if firebug is install then how could i check the size of response. can anyone help me to detect it because in my case pagemethod is taking bit more time to send back the response to client. i am not very aware the use of firebug. how to check the response size with fire but when partial postback will occur with the help of pagemethod. thanks
If you have partial postbacks then you are probably either using page methods as web-services or something (like the UpdatePannel) that requires a ScriptManager.
If you are using page methods, you can check the page's IsCallback property which returns true if the page request is the result of a callback; otherwise, false.
If you have a ScriptManager on the page you can use its IsInAsyncPostBack which returns true if the current postback is executing in partial-rendering mode; otherwise, false.
Related
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
I was reading to get some more information about the HttpResponse class. I came across an odd remark though on MSDN.
The following methods of the HttpResponse class are supported only in
postback scenarios and not in asynchronous postback scenarios:
BinaryWrite
Clear
ClearContent
ClearHeaders
Close
End
Flush
TransmitFile
Write
WriteFile
WriteSubstitution
What exactly does that mean? I rely very heavily on HttpResponse.Write in one of my projects. What exactly is an asynchronous postback scenario?
An async postback occurs when you postback through something like an updatePanel.
The major difference in an async postback is in the render.
Your normal prerender and render logic will not be called.
Only a part of the Page is updated using javascript at the front end.
This means that you cannot return another document, change the http headers, etc.
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
Ok, I thought I understood these topics well, but I guess not, so hopefully someone here can clear this up.
Page.IsAsync seems to be broken. It always returns false.
But ScriptManager.IsInAsyncPostBack seems to work, sort of.
It returns true during the round trip for controls inside UpdatePanels. This is good; I can tell if it's a partial postback or a regular one.
ScriptManager.IsInAsyncPostBack returns false however for async Page Methods. Why is this? It's not a regular postback, I'm just calling a public static method on the page.
It causes a problem because I also realized that if you have a control with AutoPostBack = false, it won't trigger a postback on it's own, but if it has an event handler on the page, that event handler code WILL run on the next postback, regardless of how the postback occurred, IF the value has changed.
i.e. if I tweak a dropdown and then hit a button, that dropdown's handler code will fire. This is ok, except that it will also happen during Page Method calls, and I have no way to know the difference.
Any thoughts?
As Tjaart points out, Page.IsAsync has nothing to do with AJAX! See MSDN for a bit more info about IsAsync and see http://msdn.microsoft.com/en-us/magazine/cc163725.aspx for a fuller description of async pages].
Page methods are web services by a different name. The ScriptManager will emit the necessary JS boiler plate to make creating an XHR that invokes the web service very easy but that's all ScriptManager has to do with them really.
As the MSDN page states, ScriptManager.IsInAsyncPostBack will only be true if the request is in "partial rendering mode" so ScriptManager.IsInAsyncPostBack will be false when you are executing a page method because that request has not been spawned as a result of a partial postback (i.e. an UpdatePanel refreshing its contents).
Now it sounds like you are getting server side event handlers being executed as an apparent result of calling a page method from JS. AFAIAA, invoking a page method using javascript should not cause the page to go through its normal page lifecycle - so Page load, init etc. and these events should not be executing. So that is strange.
Suggestion: -
See Anz's comments and Dave's replies here encosia.
Could it be that you are having similar problems to Anz? i.e. The page method is invoked and but then your page is posting back immediatly after?
This is so because ASP.NET Ajax and ASP.NET Callbacks are two different things and are implemented differently. Unfortunately you have to use both Page.IsAsync and ScriptManager.IsInAsyncPostBack.
Page.IsASync probably returns whether the page was set as Async in the page directive
<%# Page Language="vb" Async="true" ...
The autopostback flag is so that you don't get a postback after every single control action, so the user can fill in an entire form and then only create the postback and trigger all the related code.
It's not really weirdness, they designed it this way so that the server side code will always be synchronized with the client side. So if you make a drop down list selection on the page and a postback occurs then that drop down list change executes it's own code along with the control that triggered the postback. You may want to read up more on the ASP .Net page lifecycle. it made things much more clear for me.
We have a user who is having problems with a ASP.NET app. The user hasn't been available to gather many details, but at this point our best guess is that the PostBack is not occurring. Something is going wrong between when the user clicks the LinkButton and when the HTTP Request is supposed to be made.
(User does have JS enabled)
Beyond solving the immediate problem, it might be helpful for posterity to assemble the canonical list of things that can break PostBack behavior of ASP.NET controls.
If you have say a button that has a postback event as well as a javascript event on click, if the javascript event that is fired returns false postback will be stopped.
I would first check that your <form> tags are well formed and that you don't have nested <form> tags. Both times I've debugged something to do with postback this turned out to be the problem. It's confusing because it's a browser dependent issue.
Having a self-closing <script /> tag can stop postbacks occurring. Get the user to send you any javascript errors from their log. There is actually a decent JS debugger in IE8 (about the only good thing in it!).
a form with no method attribute, or method note being set to POST
an onsubmit event handler that does not return true
trying to submit the form programatically, but unable to locate the form by id as there is another element with the same id on the page