A new version of Highslide JS .NET is available today. Nothing major has changed in the .NET control, but the newer Highslide JS version includes several bug fixes, compatibility improvements, and performance benefits.

To eliminate one common source of confusion, I’ve decided to begin versioning Highslide JS .NET based on the version of Highslide JS embedded within the the control. For example, since this release is v4.1.4, it contains v4.1.4 of Highslide.

Changes in v4.1.4 include:

• Updated embedded Highslide JS script version to 4.1.4. You can see what has changed in that on the Highslide.com changelog page.
• Added ControlBarPosition property to the HighslideManager, which allows you to position the enlargement’s control bar in any corner of the image.
• Added several properties (ControlBarPreviousTitle, ControlBarNextTitle, ControlBarMoveTitle, and ControlBarCloseTitle) to control title attributes of links rendered in the control bar. Useful for localization.

As always, the free download is available on the Highslide JS .NET project page.

As you begin developing more complex client-side functionality, managing the size and shape of your JavaScript includes becomes a key concern. It’s all too easy to accidentally end up with hundreds of kilobytes of JavaScript spread across many separate HTTP requests, significantly slowing down your initial page loads.

To combat this, it’s important to combine and compress your JavaScript. While there are useful standalone tools and HttpHandler based solutions to the problem already, none of them work quite how I prefer. Instead, I’m going to show you my dead-simple method for automatically compressing and combining script includes.

To accomplish that in this post, we will select a compression utility, learn how to use it at the command line, explore a useful automation feature in Visual Studio, and apply that to keep scripts combined and compressed with no ongoing effort.

Click here to read the rest of this post »

As much as I enjoyed attending MIX09 this year, it wasn’t a difficult decision when Karsten asked me to write an article for the MIX Online site.

Reading this here, there’s a good chance the article is targeted below the amount of jQuery expertise you already have. However, it’s been brought to my attention that some readers have found it useful for sending to their more JavaScript-phobic coworkers.

So, I decided that it’s worth mentioning here after all:

It’s hard to believe that JavaScript is already well over a decade old. Often relegated to marginal tasks in its early years, JavaScript has grown to become a pillar of modern web development. With the current popularity of DHTML and AJAX, it can be difficult to find a site that doesn’t use JavaScript anymore. One of the driving forces behind JavaScript’s newfound popularity is a proliferation of JavaScript frameworks, such as jQuery.

 

Why?

Click here to continue reading this article on the MIX Online site »

The problem of how to handle dates in JSON is one of the more troublesome issues that may arise when directly calling ASP.NET AJAX web services and page methods.

Unlike every other data type in the language, JavaScript offers no declarative method for expressing a Date. Consequently, embedding them within JSON requires a bit of fancy footwork. Since the question of how I handle this problem is something asked often in emails and in comments on other posts here, I want to address the topic with its own post.

To that end, I will attempt to explain what exactly the problem is with dates in JSON, how ASP.NET AJAX solves it, and my alternative solution that I believe is easier and works just as well in most cases.

Click here to read the rest of this post »

So far, my examples of using jQuery to interact with ASP.NET AJAX services have avoided passing complex data to the server during the request. This has been intentional, because I didn’t want to over-complicate the examples.

For primarily read-only scenarios, like the RSS reader examples, passing just a few simple values to the service is often all you need. However, this scalar approach quickly becomes untenable when making real-world service calls.

In this post, I’m going to show you how passing complex types to the server helps alleviate complexity, how json2.js and a data transfer object (DTO) facilitates this, and how to use jQuery to very easily build the DTO.

Click here to read the rest of this post »

Thanks to all of your excellent feedback during the months since the last release of PostBack Ritalin, an improved version is ready for release today. With the addition of “disable all elements”, I believe the control is now feature complete, worthy of a version 1.0 release.

Notable changes in v1.0 include:

• Added disable all elements functionality to MonitoredUpdatePanels.
• Fixed a bug in the WaitImage preloading functionality, that prevented the MonitoredUpdatePanels’ WaitImages from being preloaded.
• Added both debug and release versions of the JavaScript resource. Your site’s compilation mode will determine which script version is embedded.
• Fixed a problem handling postbacks raised by Button controls that have their UseSubmitBehavior property set to false.
• Improved ClientID handling in naming containers.

As always, you can visit the PostBack Ritalin project page to download the latest version, see usage examples, and find documentation.

Recently, I’ve attended several presentations in which ASP.NET AJAX’s pageLoad() shortcut is demonstrated as interchangeable with jQuery’s $(document).ready() event. The suggestion that both methods are equivalent actually appears to be true in simple demos, but is not the case and is certain to lead to later confusion.

While they seem similar on the surface, $(document).ready() and pageLoad() are very different behind the scenes. Determining the earliest point that it’s safe to modify the DOM requires a bit of black magic, and the two libraries approach that in their own unique ways. Additionally, pageLoad() is overloaded with some extra functionality which may surprise you.

In this post, I’ll clarify the major differences between jQuery and ASP.NET AJAX’s initialization functions, what implications those difference have in practice, and show you a third alternative when working with ASP.NET AJAX.

Click here to read the rest of this post »

If you don’t properly handle the inevitable errors in your web applications, you can expect your users to eventually react about like this guy. Since they typically squelch any server-side errors, AJAX service calls are especially problematic. In fact, they rarely even throw a client-side error when they fail.

Even when a client-side error is thrown, most users won’t notice it and the ones who do notice won’t know what the error means or what to do next. In fact, I’ve found that even many developers don’t notice client-side scripting errors that occur while they’re debugging their own applications!

To help you remedy this problem in your own applications, I want to show you one way that I handle AJAX service call errors with jQuery. To do this, we will build an error-prone web service, make an AJAX request to it via jQuery, handle the resulting server-side errors gracefully, and use a jQuery plugin to attractively present those errors.

Click here to read the rest of this post »

Having used JavaScript for over a decade, I’ve read many books covering the language. Some focused primarily on syntax. Others recounted and solved specific real-world problems.

Learning a language as a set of tasks is one way to get up to speed quickly, but it’s not a very good way to thoroughly learn a language’s nuances and idioms.

While those sorts of books certainly have their place, it’s disappointingly rare to find a book which presents JavaScript as the first-class programming language that it truly is.

After reading no more than the first page of this book’s preface, I knew that I had finally found the antidote to those trite examples of compound interest calculators and the tedious minutiae of books that spend pages on alert()’s syntax. No, this book is different than the rest…

Click here to read the rest of this post »

When working directly with JSON serialized ASMX services, be it via jQuery, pure XmlHttpRequest calls, or anything else other than the ScriptManager, one question inevitably arises. That question is of the inexplicable .d attribute that appeared in ASP.NET 3.5.

What is it? Why is it there?

In this post, I’ll use both a 2.0 and a 3.5 example ASMX web service to illustrate exactly what’s going on. I’ll also show you why it’s a good change.

Click here to read the rest of this post »