I found this thread while trying to resolve my issue unfortunately this I can't seem to figure out the problem since I already have everything the way it should be.
I've got 3 updatepanels that each call a function on a .js file setup like this:
<asp:UpdatePanel ID="upPnlGeneralinfo" runat="server" UpdateMode="Conditional" ChildrenAsTriggers="true">
<ContentTemplate>
<script type="text/javascript">
Sys.Application.add_load(BindPageLoad);
</script>
Each have a different ID of course. Whenever a control calls a postback within the update panel it works, however in the js file I added a console.log("running the js file") and I can see that it's being called three times meaning it's all three updatepanels are being refreshed instead of just the one.
All the triggers are inside each of the respective updatepanels so I shouldn't need to add any triggers (I did just to make sure and it makes no difference). Shouldn't the UpdateMode=Conditional resolve this?
Also worthy to mention, none of my code behind ever calls any updatepanel.update(). I tried adding that for each control to their respective panels and that also made no difference.
Any ideas?
It doesn't necessarily mean all your update panels are being refreshed.
The MSDN docs say the client load events are raised after either a synchronous (full page postback) or asynchronous (partial page) postback.
This might mean that only one of your update panels is refreshing as intended, but all three event handlers are run again after the async postback because of how they were hooked up using MS Ajax.
MSDN excerpt:
Client Events of the Application and PageRequestManager Classes
Sys.Application.load Event
Sys.Application.add_load(handler);
Raised after all scripts have been
loaded and all objects in the
application that are created by using
$create are initialized. The load
event is raised for all postbacks to
the server, which includes
asynchronous postbacks.
-- http://msdn.microsoft.com/en-us/library/bb386417.aspx
Working with Partial-Page Rendering Events states a different event that runs only when the entire page loads:
During ordinary page processing in the
browser, the window.onload DOM event
is raised when the page first loads
-- http://msdn.microsoft.com/en-us/library/bb398976.aspx
This the regular DOM load method, not part of MS Ajax.
Therefore I assume if you hook your client code to the regular window.onload event then it will run only when the full page loads, on the first time, not on successive async postbacks (aka update panel/partial refresh).
Whether or not this knowledge is harnessable to provide the outcome you want I'm unsure. Maybe you're looking at only the MS Ajax objects for a solution when a hybrid browser/MS Ajax client solution exists.
Related
I would like to take one decision based on the question described. I had already used PageMethods in clientside code. If it triggers postback then I wanted to replace it with ajax call from client side. Can anybody clarify it?
A web method of the given page when called by a ajax call client side does NOT cause a post-back. But, keep in mind that such web methods can't referance any control on the page, nor can you use ViewState. You can use session() in a web method.
Often, in some cases, you can then adopt a update panel, and put the controls in that update panel, and thus when you click a button, or any event code from a control?
Then you don't get nor see a full page post-back. So often, a update paneal is a great way to prevent and not have full page post back. But, do keep in mind that a update panel DOES cause a partial page post-back, and even your page load event fires again.
But, a web method? No page post back occures. You often require this since a jQuery.UI pop dialog can disply things, but if that dialog needs server side code, then you can't have a post-back (since then the dialog will collapse, since you getting a new fresh re-rendered page. And even using a up-date panel will also collapse a dialog.
however, if you don't have some pop dialog showing? Then it MUCH less work and effort to just use a update panel, and not bother with all the work to wire up a ajax call to a web method.
So, in most cases I don't make the time + effort to build a ajax call.
So, look into a update panel first - often less work.
But, if you just need some value from the server, don't want a post-back, and don't want (or can't use a update-panel), then a web method is great choice. (since no post-back occurs). The big down side of a web method is no use of controls or anything from the web page can be used in that ajax call to the web method (so, you have to have the data you need client side, or pass some value(s) to the server side web method.
A pagemethod also does not cause a post-back.
Question is pretty straight forward.
Is there a technical reason for the existence of Page.PreLoad or is this just convenience to have a place where you can neatly place code that always have to be executed before the Load code?
Is there a difference between adding code in the PreLoad event handler and adding code at the top of the Load event handler?
And what would be a typical scenario where you use PreLoad?
Thanks!
What happens between Page_PreLoad and Page_Load is that all the other PreLoad event handlers (not just the handler(s) you wrote) have a chance to run. There is no reason to put code in Page_PreLoad. You see, chances are that you do want to be sure all the other PreLoad event handlers have fired (I'll explain in the last paragraph). Plus, by using Page_Load instead of Page_PreLoad, you give control adapter authors a chance to override the behavior of your implementation.
The purpose of the Page.PreLoad event (as far as I can tell) is to provide a hook for control authors. The behavior of the load phase of the page lifecycle, is that the Load event is raised on the page before it is raised on all its child controls. As a control author, you might want to perform some action after viewstate is loaded (so Init is too early), but before Page_Load is called (so Load is too late). How you do that is to add an event handler to Page.PreLoad.
Some of the built-in ASP.NET data binding controls use this hook to be able to auto-magically re-DataBind themselves when you update the control in certain ways after its viewstate has been loaded. Using a flag set in Page.PreLoad, a control can distinguish between changes you make in Page_Init and changes you make in Page_Load. If you implement Page_PreLoad and you don't take care to avoid touching any control that hooks PreLoad in this way, you're going to see undefined behavior because you don't know whether PreLoad is firing on the control or on the page first. To avoid this complication, always use Page_Load instead, as there is no reason not to.
I'm sure I've answered this a few times, but you're best bet is to have a thorough read thorugh the ASP.NET Page Lifecycle Overview from Microsoft and the ASP.NET Page Lifecycle explanation from 15 Seconds.
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.
Here's the odd situation:
we have a piece of javascript library that is being called on our onload of aspx page.
It works everytime for us, but the clients that have low speed modems get an error, because the object is not getting initialized and the aspx page is already loaded.!!
Is there any suggestions on how to call this piece of js code?
Thanks,
make sure you have your end tags.. i have seen onLoads in the not working right when your core tags are incomplete or not properly formatted
The onload even happens when everything in the page is loaded. If you have some script that is loading from a different server (ads, statistics), the onload event won't fire until those are loaded also. If their server is having problems, your onload may never fire at all, or after several minutes when the browser gives up waiting.
Instead of using onload you could put your code in a script tag as early as possible in the page, i.e. after the last element that the script needs.
If you have some external script that doesn't need a specific place in the page (statistics for example), you can move it to the bottom of the page to minimise the risk of interference with the rest of the page.
With JQuery you can call your functions with ready event :
$(document).ready(function() {
// call your functions here
});
The event will be called when the DOM is loaded.
How do you call a Javascript function from an ASPX control event?
Specifically, I want to call the function from the SelectedIndexChanged event of a DropDownList.
I get a little nervous whenever I see this kind of question, because nine times out of ten it means the asker doesn't really understand what's going on.
When your SelectedIndexChanged event fires on the server, it fires as part of a full postback. That means that for that code to run, the entire rest of your page's load code also had to run.
More than that, the code runs as the result of a new http request from the browser. As far as the browser is concerned, an entirely new page is coming back in the result. The old page, and the old DOM, are discarded. So at the time your SelectedIndexChanged event code is running, the javascript function you want to call doesn't even exist in the browser.
So what to do instead? You have a few options:
Change the page so the control doesn't post back to the server at all. Detect the change entirely in javascript at the client. This is my preferred option because it avoids odd onload scripts in the browser page and it saves work for your server. The down side is that it makes your page dependent on javascript, but that's not really a big deal because if javascript is disabled this was doomed from the beginning.
Set your desired javascript to run onload in the SelectedIndexChanged event using the ClientScript.SetStartupScript().
Apply the expected results of your javascript to the server-model of the page. This has the advantage of working even when javascript is turned off (accessibility), but at the cost of doing much more work on the server, spending more time reasoning about the logical state of your page, and possibly needing to duplicate client-side and server-side logic. Also, this event depends on javascript anyway: if javascript is disabled it won't fire.
Some combination of the first and third options are also possible, such that it uses javascript locally if available, but posts back to the server if not. Personally I'd like to see better, more intuitive, support for that built into ASP.Net. But again: I'm talking about the general case. This specific event requires javascript to work at all.
As Muerte said you have to just put the javascript, or a call to it on the page from the code behind. Personally I use this:
ClientScript.RegisterClientScriptBlock("customscript", "<script>simple script here</script>")
Of you can call the function if you already have a more complex one on the page instead of the stuff I have.
You can't do it directly from an event, because ASPX control event is server side.
What you can do is emit a Javascript in the ASPX event which will call the JavaScript function when the page reloads.
For example, if in your ASPX page you have a Javascript function called "DoSomething()", in you ASPX control event, add the following:
protected void btnSubmit_Click(object sender, EventArgs e)
{
Page.ClientScript.RegisterStartupScript(this.GetType(), "myEvent", "DoSomething()", true);
}
The last boolean parameter defines that tags are added automatically.
In the code behind, attach some markup to the server side control via its attributes collection. This assumes that the function is already in a client script file that is already available to the page.
MyServerDDLControl.Attributes.Add("SelectedIndexChanged", "MyClientSideFunction();");