I am needing a piece of javascript to be run whenever a postback occurs. Well, actually multiple pieces. This is to be done inside a custom control, so the javascript code that should be run may be used a lot of times.
I currently have it so that the custom control will create a chain of "overrides" for the __onPostBack function. I feel this is pretty messy and it also does not handle regular post backs caused by Buttons.
tl;dr: What is the best way of executing a piece of javascript code when a postback happens? (that is, execute the code before the postback hits the server)
(Also, aiming for IE 7+ and Firefox compatibility)
You could set the onSubmit event on the form:
ClientScript.RegisterOnSubmitStatement(this.GetType(), "MyScript", "alert('Hello')");
Old and new way is described here: http://weblogs.asp.net/vga/archive/2004/03/01/NoMoreHijackingOfDoPostBackInWhidbey.aspx
Related
Is it OK to use __doPostBack() or it is not recommended because it is generated from ASP.Net and we are not sure if they changed it in a next version of ASP.Net.
I would advice against it, since it's internal stuff of ASP.NET and was never meant to be used directly.
Instead, what I'm doing when I need to "manually" trigger PostBack is adding hidden "server side" button with the proper OnClick:
<asp:Button id="btnDummy" runat="server" OnClick="Foo" style="display: none;" />
Then the JS is:
document.getElementById("<%=btnDummy.ClientID%>").click();
This way I don't care how post back happens, I just trigger the natural flow of events.
You should not call it directly. You should generate the javascript call by using functions in Page.ClientScript such as:
GetPostBackEventReference
GetPostBackClientHyperlink
This will ensure that it's always compatible.
I think its perfectly fine to use directly, and have used it without fail, its just a javascript function after all.
They probably won't change it, but why call it directly?
I think it's a better strategy to trigger the event (a button click for example) and let the control trigger the postback.
I you do need to trigger the postback directly it's recommended to use the Page.ClientScript functions tenfour described.
We use it all over the place and I can't imagine it would ever be stripped out of ASP.NET. I think the fake/hidden button method is just as hokie if not worse. If you use the fake button approach, then you get no option to pass in the __EVENTARGUMENT. I like using __EVENTARGUMENT to pass my data to the server better than creating hidden fields, because it would be more difficult for a hacker to compromise than simply posting back some hidden field to my page. I also don't like the idea of creating fields and controls on the page if they are not even going to be displayed. I am sure that the fake button approach is probably easier for a newbie coder to understand. That being said I am searching for a more elegant way to approach this, but still find myself calling
__doPostBack('%=UpdatePanel.ClientID%>','MyData')
in some cases.
I've heard different stories about ASP.NET and JavaScript: that it works fine with Javascript turned off, that only some parts don't work, and that nothing works at all.
How exactly are ASP.NET applications affected if JavaScript is turned off in a client's browser? What parts don't work (if any)?
For example, will RequiredFieldValidators still work? What about UploadControls? AJAX UpdatePanels and AsyncPostBack's? FileUploads? Do page codebehinds still run?
Forgive my ignorance, I can't seem to find much about the issue that is in-depth.
Client-side validation and Ajax won't work, including async postbacks and any control that requires Javascript in order to work.
Server-side validation (which should always happen anyway) and full postbacks and such should always work, and i think a FileUpload control will as well. The biggest difference would be that someone wouldn't see that the data they entered happened to be invalid til the form was submitted.
LinkButtons don't work because they render out a javascript: target.
If you use GridView controls with ButtonColumns then these won't work as the buttons are javascript too. One way around this is to use a TemplateColumn and add <asp:Button> objects inside it.
Also GridView paging and sorting is JavaScript out-the-box so you'd have to write custom paging and sorting.
Also any control with AutoPostback set to true (e.g. a DropdownList) will not auto-postback. You will be able to catch the SelectedIndexChanged but ONLY when the next postback happens.
Any control that "does something" on the client side without a full page request going back to the server(ie. the whole page reloading) is done via JavaScript , and will not work with JavaScript turned off.
Remember HTML is static, so anything that "changes" in the browser window other than CSS hover effects or anything that calls back to the server without a full page reload, is done via JavaScript, and you cannot expect that to work with JavaScript disabled on the client.
We have a method on an asp.net page that is called on a button click. The problem is that the method take a long time to process. I've been asked to have the page call the method (or call the postback) and then display the jquery.ui dialog which will let the user know that this process could take a long time. I'm looking at serializing the asp.net form and doing a $.post() but to be honest I'm completely stuck on whether this will even work and how I can prevent the actual postback from happening and just displaying the dialog. Has anyone had any experience with doing this that can give me some pointers?
I found this http://dotnet.dzone.com/news/eliminating-postbacks-setting- but I'm not sure if it's a bit OTT. The article is a little long winded.
Hope someone can help.
That would be easier if you can use an UpdatePanel (which basically boils down to ASP.NET's way of doing what you're considering with the $.post(), but automatically gets the ASP.NET specific stuff right).
Then, you can do something simple like this: http://encosia.com/2008/10/04/using-jquery-to-enhance-aspnet-ajax-progress-indication/
You can send a post request through javascript (AJAX) without using asp.net's ajax framework. So in other words do it manually. Ajax would be perfect in this case, because you are trying to show loading indicators on the front-end while you are waiting for a response from the server.
To do this, take the logic out of your button_click method and put it in a separate page (text.aspx see below). Then you can call that page like this (using JQuery):
$('#ProgressIndicator').show();
$.post("test.aspx", function(data){
alert("Data Loaded: " + data);
$('#ProgressIndicator').hide();
});
If you can't use JQuery in your project, see: AJAX
On a rather complicated screen with a big updatepanel, I'm running into the following problem:
If a user clicks on a certain button 6 or 7 times really fast, it seems to eventually process the last request out of turn and problems occur. Specifically, there's an xml document in session state, and it gets out of sync.
What I really want to do is block clicks to this button until the postback completes. I know I could probably find an easy way to do this with Javascript, but it seems like it might be built-in.
Any thoughts?
Note: The answers below are helpful, but they haven't solved the problem. After disabling the linkbutton with onClientClick and then allowing it to come back after the postback enabled again, the problem persists. It's almost as if the updatepanel isn't quite done with everything even though it has drawn the fresh, enabled linkbutton on the screen.
More notes (solved!): I solved this one by using BlockUI (jQuery plugin). See my answer below.
ASP.NET UpdatePanel always honors the last request. If you make a request while one is processing, the first requests gets terminated and the current one is processed. It was designed and built to work this way.
I would disable the button with JavaScript once it has been clicked.
UpdatePanel? I will assume you are using MS AJAX, if so I will recommend you download the AJAX toolkit if you have not done so. This toolkit comes with many ready to use controls, and extensions to help you in your AJAX enabled app. For example, there is one extension called "ConfirmButton" that will help you prevent the user from clicking in a button more than once, and it also does it in a very cool and elegant manner.
Another option will be to use JavaScript or better yet, create a custom button control that has a property to be disabled after it is clicked, if you do that, it will be really easy to reuse it in your other applications.
Hope this helps.
In a home-rolled AJAX framework I worked on awhile back, we simply logged the last call in javascript (javascript function call with many parameters) and prevented subsequent calls with identical parameters. It wasn't ideal, but it did the trick in a pinch.
I was having some "Asyc" problems with infragistics control, but after adding ScriptMode="Release" in Scripmanager the problem was resolve.
The link below solved my problem in about half an hour. Just going with a javascript disable (and I tried several different ways...) did not do the trick due to the timing of the updatepanel.
Disabling UpdatePanels While an Asynchronous Postback is in Progress
I want to set a breakpoint on the __DoPostBack method, but it's a pain to find the correct file to set the breakpoint in.
The method __DoPostBack is contained in an auto-generated js file called something like:
ScriptResource.axd?d=P_lo2...
After a few post-backs visual studio gets littered with many of these files, and it's a bit of a bear to check which one the current page is referencing. Any thoughts?
If you using IE7 for testing you can use View -> Script Debugger -> Break on next statement and then just click the button that generates the event(__DoPostBack)
TBH, I dont think there is much value in setting a breakpoint within the Javascript since it pretty much comes straight back to the server anyways.
It would be best to set breakpoints in your server code.. Depending on what you are trying to debug this will be in different places.. Either in the page event cycle or a controls IPostBackEventHandler.RaisePostBackEvent handler.