Arnold Matusz's Blog

In my last post I blogged about how jQuery $(document).ready() and ASP.NET Ajax asynchronous postbacks can be made to behave well together. The issue is that normally $(document).ready() is called when the DOM is ready to be manipulated. But this doens’t happen after an ASP.NET Ajax asynch postback occurs.

This means that the initial jQuery bindings won’t be automatically available after the asynchronous postback is over. I underline “automatically” here because my last post describes more possibilities, how this issue can be worked around. » Continue reading ...

I’ve been a bit skeptic about the thought of combining ASP.NET Ajax with jQuery, partly because I didn’t really know what the impact was going to be. But jQuery is very fast, very appreciated throughout general opinion, there are extremely many plugins available for free, writing your own plugins only requires little JavaScript knowledge (opposed to writing your own extender in .NET, like controls in the AjaxControlToolkit).

To be sincere, there is a very short learning curve so there is no reason for not trying jQuery. I’ve tried with regular web applications, but when I coupled jQuery with ASP.NET Ajax on little niggle stood out. » Continue reading ...

Using Ajax in a web application makes a better user experience and if used well, it even improves performance! But it's not all advantages. With the change of a technology, of an approach we need to adjust our way of thinking and the way we apply our solutions for different task.

This might be a bit abstract, so I'll get specific about what I mean. As often met, when you click certain controls on a webpage, you expect to see an outcome, a result or a message as a response to your "request". What Ajax does is ... it replace only certain regions of your webpage. If that region isn't in the visible in the current scroll position of your page in the browser, you won't see the effect. » Continue reading ...

Although the ModalPopupExtender isn’t new at all there are still countless poeple who search the web for a comprehensive sample on how a ModalPopupExtender is used from a GridView.

First of all you’ld need to have a Button in each row which should trigger the ModalPopupExtender, then you would need to have an instance of a ModalPopupExtender with the TargetControlID set to the ID of that Button. » Continue reading ...

Restricting the user from leaving certain fields blank is often mandatory, because we don't want to have empty fields in our database, or we may want the user to specify exactly how many products he wishes to order. Asp.net comes in really good here with the Validation Controls. For my example the RequiredFieldValidator is perfectly suited because it displays a little error message for the control it validates.

All is fine until you have 40-50 fields that have to be filled out. In this case it's of good practice to use the ValidatioSummary control which summarises all the error messages from the ValidationGroup and shows them either in text on the page or as a Javascript alert().  » Continue reading ...

While writing a short piece of code for my global exception handling post I figured out a nice fact. What I wanted to achieve is to have redirection to a custom error page which displays exception details. This can be easily done by using Response.Redirect() (to ex: ~/exception.aspx"), but this will completely lead to another page. This is not usefull if I'm interested in the actual URL where the exception has been thrown. (ex: ~/products.aspx?catid=4&pageid=7 ..."). By using Response.Redirect() you end up with "/exception.aspx" as the URL in the browser.

An obvious solution at first sight is ... we need to use Server.Transfer() which won't create a new Context (i.e.: the url in the browser will stay the same but we show the contents of a completely new page). And of course this is all fine ... until you need to use this functionality in an ASP.NET AJAX enabled website in an UpdatePanel.

By calling Server.Transfer() during an asynchronous postback the following alert will be displayed:

Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.

Details: Error parsing near '

<!DOCTYPE html P'.

The reason why you can't use a Server.Transfer() in an UpdatePanel is more and more obvious when you think about what AJAX is. We only request small pieces of markup which replace little portions of a page, the whole point of AJAX is to avoid downloading the whole page again. This means that when triggering an async postback, the PageRequestManager expects to receive some small portion of HTML, but because the Server.Transfer() call was made the actual response is the markup for a completely new/different page (which begins with the DOCTYPE definition, this is what you can see at the end of the exception message).

If you decide to use a Server.Transfer() in an UpdatePanel you can avoid this exception by setting your Trigger to a PostBackTrigger. (i.e. The control which fires the method where Server.Transfer() is called won't cause an async postback!).
» Continue reading ...