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.
Related
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
I currently have a simple form that when you click the "save" button will persist it to the database.
I would like to use JQuery to do the callback for me and popup a "Save completed" div window/div of some sort.
My only problem is how do I call the btnSave_Click() event from JQuery?
If I use PageMethods the method would have to be static and therefore lose access to my textboxes and other page controls?
Thanks,
Goosey
Are you explicitly trying to avoid passing the values of the input controls? because that would be much easier.
Using a lightweight jQuery call to do the post but then expecting a full control hierarchy in the code behind to pull data out? What's the intent here? If you require that, it would probably be easier just to submit the page, and register javascript to run to pop the success message up on load.
Personally, I think the page method route and $.ajax or $.post is a much cleaner, separate way to solve the issue. That way you can just show the popup as part of the success callback.
You can use onClientClick
Have a look at the jQuery Form Plugin, it can change existing forms into Ajax forms.
You need to set __EVENTTARGET to the id of the control that you want to simulate causing the postback if you want to use the same handler. I seem to recall having to replace the underscores with dollar signs as well, but I could be wrong on that. The hidden inputs, __EVENTTARGET and __EVENTARGUMENT, are used by the framework to identify which control caused the postback. There's a nice discussion of the server side issues in this blog post, though it doesn't talk about AJAX. Google for __EVENTTARGET and postback for more info.
ASP.NET has a number of nice features regarding making data input pages:
Adding input controls is easy (<asp:...).
The system automatically generates member variable for the controls.
Post-backs automatically populate the members variable with the returned values.
and some not so nice bits
post-backs seem to be tied to JavaScript for even the simplest of cases. For instance, with statically defined pages, using only basic controls, that are known at compile time.
My questions:
Is is possible to get the first list without the second?
What features does that JavaScript give the user?
What does that JavaScript actually do?
What is the technical reasons that it's used even in trivial cases?
As it happens my assumption were in error: See here
It really depends on the types of controls you are trying to use here -- the only ones that implement javascript are those that can't natively cause a postback (ie, an input/submit button are the only two that can). If you are using a LinkButton, ImageButton, or anything that you set "AutoPostBack = true" on will turn javascript on in order to cause a postback.
Other controls can also potentially use javascript if they are more advanced such as the Calendar. The technical reason for using javascript here is to provide automated postback when the controls require more advanced server interaction -- think about it, a link is meant to only ever be a link and if we're trying to make it operate as a button we have to force it to do just that through javascript interaction.
So that being said, yes you can definitely use ASP.NET without it having javascript you just have to avoid the controls that implement it by including functionality you couldn't possibly have without it. You can just as easily add HTML controls and add the runat="server" attribute and gain member variables to the control from code-behind.
Here's what came to my mind:
What features does that JavaScript give the user?
Client side validation.
What does that JavaScript actually do?
For exmaple, it ensures that the correct (server-side) event handlers are called, by setting the __EVENTTARGET hidden field.
Is is possible to get the first list without the second?
You can use normal HTML controls instead of the ASP.NET controls. Then on the server-side, you can read the control's values from the Form collection.
I assume you mean the javascript associated with an <asp:Button /> control, right?
In addition to the reasons mentioned by Fooberichu, the javascript can also help with ASP.NETs client side validation framework.
But I think it's primary use is to alert the framework what events it should fire on the postback in the page behind.
So if you had two buttons on the form, SaveButton and DeleteButton, the javascript helps the framework know whether it should execute the SaveButton_Click event or DeleteButton_Click event.
Hope this helps.
I need the ability to temporarily turn off the partial page update behavior for an ASP.NET Ajax / UpdatePanel based page. (The reason is to circumvent the issue where IE blocks "automatic file downloads" for downloads generated as a result of this postback, but I don't want to distract from my original question)
I looked at the client side javascript libraries hoping to find a switch somewhere. I think a solution might involve using javascript to override the 'onclick' event handler for the control that acts as the trigger, and then calling "submit" on the form itself..
Also, using the EnablePartialRendering property on the server-side ScriptManager control won't work because that is done when the page is being built. I need to be able to do this as a result of switching a drop down list box.
Any ideas?
Cheers!
/ Sean
Well, after much trial and error, I found two approaches that seemed to work:
Use Javascript to manually submit the top level form associated with the page. This usually has the ID of "form1".
Create a button that is outside of any UpdatePanels and use Javascript to click the button.
I wound up using the second approach, since it allowed me to handle the event with a specific routine without the need to guess that my postback came from a Javascript call.
This is an example of the code that performed the postback:
...
if (isDownload) {
document.getElementById('FullPostbackSubmitter').click();
return;
}
...
Hope this helps someone else!
You can set the EnablePartialRendering property of your ScriptManager to false.
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