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
Related
I've got an asp:TextArea that I would like to do some processing (filtering a list) as the user types. I'm sure I could do the filtering within a javascript function called via the onkeyup event, but I'd prefer to do it in my VB.NET code.
Is it possible to do such a thing, or should I just stick with the Javascript? If the latter, could you please explain why?
Thanks!
Stick to the javascript, for one simple reason: postback will lag.
Think about how fast you type. And think about how fast your server responds when a postback is submitted. Now, what will happen when the user types "Hello, world!" in two seconds? He'll get to "Hell" and then the browser will load the postback response. And the user will be back at "H". If every time your user tries to type something you delete a couple of letters, he'll hate your interface.
Doing it with javascript isn't harder than doing it with VB.Net - use jQuery or some other javascript library that makes your life easy, and you'll be filtering that list without keeping your users waiting.
I'd stick with Javascript. otherwise you are going to be posting back to the server each time the user enters a letter which is going to be slow and awkward from a usability perspective.
Depends on the number of possible Users.
Imagine that plenty of users are entering text simultaneously. This would overstress your Server bandwith/RAM/CPU. But if thats not an issue you could use Ajax and make an Async Postback on the Textbox' client event OnChange.
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.
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'm using a ReportViewer control which often runs into problems with the javascript associated with UpdatePanels in ASP.NET. I've created a second page which is very simple, no Update Panels. What's the best way to link the two pages? An iframe sounds bad. However, having to run a report, then be returned a link to the results also sounds bad. Sending the user to the simple display won't work in this case. Any suggestions, am I seeing things wrong here?
What I would do is rewrite the page that uses an update panel such that it uses straight javascript web method calls. This would remove the need for the reportviewer control to be on a seperate page because you would no longer need an update panel.
I have a problem with maintaining state in an ASP.NET AJAX page. Short version: I need some way to update the page ViewState after an async callback has been made, to reflect any state changes the server made during the async call.
This seems to be a common problem, but I will describe my scenario to help explain:
I have a grid-like control which has some JavaScript enhancements - namely, the ability to drag and drop columns and rows. When a column or row is dropped into a new position, an AJAX method is invoked to notify the control server-side and fire a corresponding server-side event ("OnColumnMoved" or "OnRowMoved").
ASP.NET AJAX calls, by default, send the entire page as the request. That way the page goes through a complete lifecycle, viewstate is persisted and the state of the control is restored before the RaiseCallbackEvent method is invoked.
However, since the AJAX call does not update the page, the ViewState reflects the original state of the control, even after the column or row has been moved. So the second time a client-side action occurs, the AJAX request goes to the server and the page & control are built back up again to reflect the first state of the control, not the state after the first column or row was moved.
This problem extends to many implications. For example if we have a client-side/AJAX action to add a new item to the grid, and then a row is dragged, the grid is built server-side with one less item than on the client-side.
And finally & most seriously for my specific example, the actual data source object we are acting upon is stored in the page ViewState. That was a design decision to allow keeping a stateful copy of the manipulated data which can either be committed to DB after many manipulations or discarded if the user backs out. That is very difficult to change.
So, again, I need a way for the page ViewState to be updated on callback after the AJAX method is fired.
If you're already shuffling the ViewState around anyway, you might as well use an UpdatePanel. Its partial postbacks will update the page's ViewState automatically.
Check out this blog post: Tweaking the ICallbackEventHandler and Viewstate. The author seems to be addressing the very situation that you are experiencing:
So when using ICallbackEventHandler you have two obstacles to overcome to have updated state management for callbacks. First is the problem of the read-only viewstate. The other is actually registering the changes the user has made to the page before triggering the callback.
See the blog post for his suggestions on how to solve this. Also check out this forum post which discusses the same problem as well.
I actually found both of those links you provided, but as noted they are simply describing the problem, not solving it. The author of the blog post suggests a workaround by using a different ViewState provider, but unfortunately that isn't a possibility in this case...I really need to leave the particulars of the ViewState alone and just hook on to what is being done out-of-the-box.
I found a fairly elegant solution with Telerik's RadAjaxManager. It works quite nicely. Essentially you register each control which might invoke a postback, and then register each control which should be re-drawn after that postback is performed asynchronously. The RadAjaxManager will update the DOM after the async postback and rewrite the ViewState and all affected controls. After taking a peek in Reflector, it looks a little kludgy under the hood, but it suits my purposes.
I don't understand why you would use a custom control for that, when the built-in ASP.NET AJAX UpdatePanel does the same thing.
It just adds more complexity, gives you less support, and makes it more difficult for others to work on your app.