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.
Related
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
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.
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.
I'm having the same problem I had yesterday... The solution Aristos provided helped solve the problem, but I have other places sending updatepanel postbacks causing the same problem.
When an update panel is updated and another request for an update is called before it has a chance to render the first updates, the entire page refreshes instead of just the update panel.
I used fiddler to see what was going on and here's what happens... If I wait for the request to return before doing another request I get this:
21443|updatePanel|dnn_ctr1107_CRM_SalesTool_LeadsUpdatePanel|
But if I don't wait, I get this:
66|pageRedirect||http://mysite.com/salesdashboard.aspx|
The code from the previous question is still the same except I added UpdateMode="Conditional" to the update panel.
Any ideas? Or is the only solution to this making sure that 2+ updates for any number of update panels (as long as they're on the same page) never happen?
Thanks,
Matt
Maybe microsoft automatic ajax can not handle 2 request at the same time because he needs to know what is the post back every time, so probably if you click when he wait for a return, then he knows that the post back, has change, so he by pass ajax to be soure for correct return.
I can think 2 ways. One way is to make it by your self using jQuery and ajax and avoid UpdatePanel.
Second way, is to block the clicks when you wait for the return, or make a mechanism to place the request, the one after the other.
This code can help you know when you block the input and when you release it, or do what ever you think.
$(document).ready(function() {
var prm = Sys.WebForms.PageRequestManager.getInstance();
prm.add_initializeRequest(InitializeRequest);
prm.add_endRequest(EndRequest);
});
function InitializeRequest(sender, args) {
LastIdCaller = args.get_postBackElement().id;
}
function EndRequest(sender, args) {
}
I could be wrong, but if I'm right then you can't do multiple ajax request if you are using asp.net WebForms. In asp.net WebForms there is only one Form element on a page. Multiple ajax requests on the same page require multiple form elements for each. Html is designed to post back inside a form element and the mechanism that handles said postback is the form, it's the container. Only one can post back at a time. So because Asp.Net WebForms only has one form element per page, you can only do 1 ajax postback per page.
Optionally, you can create generic ASHX Http Handlers to do your form logic and use JQuery Ajax to post back to the Generic Http Handlers. In which case you can do as many of those at a time as you want.
Generally I use ASHX handler's any time I need to serve images that change, like on the fly imaging. I also use them for large data outputs. E.g. the ASHX handler returns a big dump of JSON. I do an Ajax Postback to the ASHX handler to get a set of data in JSON and append it to a table etc and I call the ASHX handler repeatedly on a timer to get new Data as it comes in (say a 5 min timer) etc.
If you gave some more context on what your trying to do I might be able to provide you with alternative solutions.
Edit: I looked at your other post you linked and I think an ASHX handler would serve you well. You can design the ASHX handler to return your Search Data in JSON. You can use Request varaibles in the ASHX handler and you can send post data to the ASHX Handler with JQuery.Ajax.
You should be able to fire off multiple requests each with it's own Success Function. Then you would need to write the javascript in such a way that as it's processing the JSON data from the ashx handler it can merge with other requests as they finish.
I implemented a save-draft trick using an update panel whereby I handle the updatepanel's asynch postback on the server side and then to avoid resending the same html data I throw an exception with the current datetime as message and then capture it on the client side where i do some transformation and html injection to let the user know that a draft of his current work has been saved (TERRIBLE!).
The original idea was to handle the asynch postback and then override the rendering method of the update panel to send xml or javascript data that could be captured and processed on the client side stopping the update panels refresh from occuring.
Has anyone tried this kind of functionality using update panels?
I don't think that an UpdatePanel is really what you want here. If you're wanting to get the response back and have the best control over the response you should look at standard AJAX requests.
An UpdatePanel isn't something that you can really control the response of all that well, you can tie into the endRequest event handler on the PageRequestManager, there you can check the respose. Here's the details on the eventArgs you get back - http://msdn.microsoft.com/en-au/library/bb384175.aspx
But throwing an Exception isn't a good idea because nothing exceptional has happened, which is what an exception is ;)