Delay's Blog : AJAX Control Toolkit

Successfully passing the baton [AJAX Control Toolkit release!]

Delay — Fri, 22 Aug 2008 08:23:00 GMT

Bertrand Le Roy posted earlier today about the new 20820 release of the AJAX Control Toolkit! In addition to being compiled for the recently available .NET 3.5 SP1 platform and containing a new user-contributed control (MultiHandleSlider by Daniel Crenna), this release is also notable from my perspective because it represents the first release for which I was not directly involved. As much as I've enjoyed working on the Toolkit, there are only so many hours in the day; organizational changes and my present responsibilities developing for Silverlight are taking up all of my time. So it has been fantastic to have Bertrand continue moving the Toolkit project forward and taking care of all the many tasks that go into publishing a new release.

Congratulations to Bertrand - and all the individual contributors! Thank you for the hard work that made this release possible!

Brought to you by community contributions [AJAX Control Toolkit release!]

Delay — Fri, 29 Feb 2008 23:58:00 GMT

We've just published the 20229 release of the AJAX Control Toolkit! This release was one of our most community-driven and features 10 contributor code patches with improvements across the set of Toolkit controls. We really appreciate community involvement and specifically recognize our contributors in a Toolkit Patch Hall of Fame.

This release addresses over 200 users votes in areas including:

Tab support for Visible=false
ValidatorCallout support for server-side validation
ValidatorCallout support for CSS styling
Calendar improvements for Safari
Tab support for starting out blank

As always, it's easy to sample any of the controls (no install required). You can also browse the project web site, download the latest Toolkit, and start creating your own controls and/or contributing to the project!

If you have any feedback, please share it on the support forum!

Getting the Toolkit working with the VS 2008 web site designer [AJAX Control Toolkit 11119 release update!]

Delay — Fri, 30 Nov 2007 01:26:00 GMT

Since last week's release of the 11119 version of the AJAX Control Toolkit, some people have reported problems using the .NET 3.5 flavor of the Toolkit with the Visual Studio 2008 web designer. Our team has just updated the 3.5 ZIPs (AjaxControlToolkit-Framework3.5.zip and AjaxControlToolkit-Framework3.5-NoSource.zip) available from the 11119 release page to address the issue. Whereas the old assembly had version number 3.5.11119.*, the new assembly has version number 3.0.11119.*. This is the only change to the Toolkit and only the 3.5 version has been updated.

If you have already downloaded the 3.5 flavor of the Toolkit, please remove the Toolkit from your Toolbox (if present), download the new 3.5 ZIPs, extract the new files over top of the existing ones, and designer support should work as expected. We apologize for any inconvenience this may have caused.

A big day for development tools [AJAX Control Toolkit release!]

Delay — Tue, 20 Nov 2007 04:53:00 GMT

A short while ago we published the 11119 release of the AJAX Control Toolkit to coincide with today's release of .NET 3.5 and Visual Studio 2008! As usual, we have published "source" and "no-source" versions for .NET 2.0/Visual Studio 2005 and .NET 3.5/Visual Studio 2008.

The content of the 11119 release is largely the same as our previous 10920 release, with most changes being minor tweaks to the .NET 3.5 flavor of the Toolkit:

All web.config files were updated to match the shipping configuration of ASP.NET/AJAX 3.5.
The AssemblyVersion/AssemblyFileVersion of the .NET 3.5 version of AjaxControlToolkit.dll was changed from 1.0.x.y to 3.5.x.y to more clearly identify its association with .NET 3.5 (the .NET 1.0 version of the assembly remains as 1.0.x.y).
All of the new code analysis warnings resulting from improvements to the VS 2008 code analysis feature were addressed.
The "Add Page Method" design-time feature was re-enabled because the blocking issue in VS 2008 Beta 2 was been fixed.
A design-time workaround for XML namespace alterations to a control's inner property content was removed because the problematic VS 2008 Beta 2 behavior was addressed.

The following changes were common to both the .NET 1.0 and .NET 3.5 flavors of the Toolkit:

A minor documentation correction was made to the ModalPopup sample page's descriptions of the OkCancel* properties.
A fix was made to AutoComplete to better support the use of purely numeric values.

If you have any feedback, please share it with us on the support forum!

You voted lots, we fixed lots [AJAX Control Toolkit release!]

Delay — Fri, 21 Sep 2007 22:17:00 GMT

Last night we published the 10920 release of the AJAX Control Toolkit. This release continued our trend of focusing on the most popular bugs and work items identified by the user community in the support forum and online issue tracker. A number of popular issues got fixed in this release, addressing nearly 1000 user votes!

The release notes from the sample web site detail the improvements:

General fixes:

Controls with Embedded styles (Calendar, Tabs and Slider): Toolkit controls no longer need explicit style references when loaded asynchronously. For example, if a Calendar control is placed inside an UpdatePanel and made visible on an UpdatePanel postback, the embedded styles are now loaded properly.

PopupBehavior positioning (AutoComplete, Calendar, DropDown, HoverMenu, ListSearch, PopupControl and ValidatorCallout): PopupBehavior now respects the position of its parent element even when the browser window is very narrow or the parent element is close the window edge.

Focusing extended controls (Accordion, CollapsiblePanel, DropShadow, Tabs): Pages that use Toolkit controls which re-parent DOM elements can use a workaround to focus a specific element on page load. The new method Utility.SetFocusOnLoad ensures that the desired control receives focus.

Control specific fixes:

Calendar: Property to specify the position of Calendar, a default date feature that allows the calendar to start out with a selected date, and a consistent show, hide and focus story that makes the Calendar user experience more intuitive.

ModalPopup: Ability to disable repositioning of the ModalPopup in response to window resize and scroll.

ConfirmButton: ModalPopup functionality now supported in addition to the regular windows alert dialog.

MaskedEdit: Extended Textbox no longer uses Invariant culture if no CultureName is specified and falls back to the Page Culture.

AutoComplete: Allow users to associate additional data with the AutoComplete suggestions.

Slider: Slider can be easily customized using its various CSS properties.

As with the previous release, we have published "source" and "no-source" versions for .NET 2.0/Visual Studio 2005 as well as for .NET 3.5/Visual Studio 2008 (still in Beta). Unique to the 3.5/2008 versions are the following:

Features:

JavaScript IntelliSense support: We have added reference tags to all Toolkit JavaScript files that enables you to take advantage of new features in Visual Studio 2008 Beta 2. With the multi-targeting support in this Visual Studio Beta, IntelliSense will be available for the ASP.NET AJAX 1.0 flavor of the Toolkit as well. This article discusses the reference tag feature in detail.

Extender designer support: Enhanced designer support for Toolkit controls using the new "Add Extender" user interface.

One thing we'd hoped to include with this release didn't quite make it in: our new automated testing framework. This framework is based on a different approach than our current framework - one that makes it easy to add additional test cases and leverage existing ones across new scenarios. The new testing framework has already dramatically improved our test coverage, helped identify new issues, and made fixing existing issues less risky!

But we've been iterating on the new framework for the past couple of weeks and faced the usual decision when it came time to finalize this release: slip or ship. We slipped our release date a little in the hopes that we'd be able to include the new framework with this release, but eventually decided not to delay all the great new Toolkit code any longer. We wanted our users to take advantage of the new bits ASAP - so stay tuned for more on the new testing framework in a future release!

If you have any feedback, please share it with us on the support forum!

A new Framework deserves a new Toolkit [AJAX Control Toolkit updated for .NET 3.5 Beta 2!]

Delay — Fri, 27 Jul 2007 06:32:00 GMT

Earlier today Microsoft announced Beta 2 of Visual Studio 2008 and the .NET Framework 3.5. As usual, Scott Guthrie has a bunch of reasons why the new stuff is cool. My team has one more reason to add to the list:

We've just updated the 10618 Toolkit release with Beta 2 versions of the AJAX Control Toolkit that work seamlessly with VS 2008 and .NET 3.5!

The Toolkit's new "Framework3.5" downloads contain the latest 10618 Toolkit code in a VS 2008 Beta 2 solution/project. What we've done is make a handful of tweaks to better integrate with the new VS 2008 web designer enhancements for ASP.NET AJAX extenders. As you'd expect, the Toolkit controls work the same as before - but the development experience with VS 2008 is better than ever.

Download Visual Studio 2008 with the .NET Framework 3.5, the .NET 3.5 Beta 2 Toolkit, and find out for yourself!

And if you have any feedback, please share it with us on the support forum.

Script combining made better [Overview of improvements to the AJAX Control Toolkit's ToolkitScriptManager]

Delay — Thu, 21 Jun 2007 01:14:00 GMT

The 10606 release of the AJAX Control Toolkit introduced ToolkitScriptManager, a new class that extends the ASP.NET AJAX ScriptManager to perform automatic script combining. I blogged an overview of ToolkitScriptManager last week (including an explanation of what "script combining" is). This post will build on that overview to discuss some of the changes to ToolkitScriptManager in the 10618 release of the Toolkit.

The most obvious change is the addition of an optional new property: CombineScriptsHandlerUrl. Left unset, ToolkitScriptManager works just like before; setting CombineScriptsHandlerUrl specifies the URL of an IHttpHandler (feel free to use @ WebHandler to implement it) that's used to serve the combined script files for that ToolkitScriptManager instance instead of piggybacking them on the host page itself. Implementing this handler is simple: just use the CombineScriptsHandler.ashx file that's part of the SampleWebSite that comes with the Toolkit! :) If you look at how that handler works, the ProcessRequest method simply calls through to the ToolkitScriptManager.OutputCombinedScriptFile(HttpContext context) method which is public and static for exactly this purpose. OutputCombinedScriptFile does all the work of generating the combined script file and outputting it via the supplied HttpContext - in fact, this is the same method that ToolkitScriptManager now uses internally to output a piggybacked combined script file. Because adding a handler in this manner doesn't require modifying the server configuration, CombineScriptsHandlerUrl can also be used by people in hosted and/or partial trust scenarios.

At the end of my previous post, I mentioned two tradeoffs that were part of switching from ScriptManager to ToolkitScriptManager. Both of those tradeoffs are addressed by the 10618 ToolkitScriptManager - plus one more I didn't know about then and another that's implicit:

Using CombineScriptsHandlerUrl incurs no unnecessary load on the server. One of the tradeoffs of the piggyback method for generating combined script files is that it involves a little bit of extra processing as part of the host page's page lifecycle that's not strictly necessary for the purposes of generating the combined script file. ToolkitScriptManager manages the page lifecycle processing to minimize the impact of piggybacking, but can't eliminate it all. However, using CombineScriptsHandlerUrl with a dedicated IHttpHandler doesn't involve any such overhead and helps keep things as efficient and streamlined as possible. The host page doesn't get reinvoked and the dedicated IHttpHandler does no more than it needs to.
Using CombineScriptsHandlerUrl won't interfere with URL rewriting. Customers using URL rewriting with their web sites pointed out that the piggybacking approach to combined script generation might require them to revise their URL rewriting rules to account for the unexpected page requests with the special combined script request parameter. ToolkitScriptManager tries to be as easy to use as possible, so one of the nice things about setting the new CombineScriptsHandlerUrl property is that web site authors can choose whatever URL works best for them to be their combined script file handler, thereby avoiding conflict with existing URL rewriting rules.
Using CombineScriptsHandlerUrl makes it more likely that cached script files will be reused. When piggybacking combined script URLs, the presence of the host page's base URL in the combined script URL means that any cached script files generated by page A will not be usable by page B (which has a different base URL). Of course, once the user's browser caches the combined script files for pages A and B, the cached versions will be used and there is no server impact - but page B won't benefit from page A's cached file even if the combined script files are otherwise identical. When pages A and B both use the same set of extenders and CombineScriptsHandlerUrl is specified, the combined script file URL generated by pages A and B will be identical (because the combined script file handler base URL will be the same for both) and therefore the combined script file cached by the user's browser for page A will be automatically used for page B as well. For web sites with common extender usage patterns (such as a TextBoxWatermark'd search box in the corner of every page), the caching benefits of CombineScriptsHandlerUrl could be significant.
The URLs used to specify combined script files are considerably less verbose. Rather than including the full script name for every script in the combined script file (often upwards of 20 or 30 characters), the hexadecimal representation of their String.GetHashCode is used instead (8 or fewer characters). While the baseline combined script URL length has grown by a bit due to some other changes, by far the most significant source of URL length was the script names, so the new URLs are shorter and less likely to get long (even on pages with lots of extenders). This improvement applies whether CombineScriptsHandlerUrl is specified or not, so piggybacked URLs are shorter, too. Note: Because hash code collision is now possible (though extremely unlikely), there's a bit of code to detect that scenario and throw an informative exception. (Just change either of the script names slightly to resolve the collision.)

A handful of other fixes and improvements were made to ToolkitScriptManager for the 10618 release. Notably:

The CurrentUICulture is now embedded in the combined script URL so that changing the browser's culture while viewing a site will properly update the culture of the site's extenders.
ToolkitScriptManager's check for a script's eligibility to participate in script combining now includes a check for the WebResource attribute which is one of the things that ASP.NET's ScriptResourceHandler requires in order to serve an embedded resource. Consequently, an assembly's embedded resources without a corresponding WebResource attribute are no longer eligible for script combining (without needing to use the ExcludeScripts to explicitly remove them). This makes ToolkitScriptManager's behavior more consistent with that of ScriptResourceHandler.
The "magic" request parameter for the combined script file changed from "_scriptcombiner_" to "_TSM_HiddenField_"/"_TSM_CombinedScripts_". _TSM_CombinedScripts_ is simply a rename of _scriptcombiner_, while _TSM_HiddenField_ now specifies the HiddenField that's used for tracking which scripts have already been loaded by the browser. This ID is implicitly available when piggybacking, but is not available in the CombineScriptsHandlerUrl case, so it has become part of the URL. For completeness, the new form of the combined script URL is now:
.../[Page.aspx|Handler.ashx]?_TSM_HiddenField_=HiddenFieldID&_TSM_CombinedScripts_=;Assembly1.dll Version=1:Culture:MVID1:ScriptName1Hash:ScriptName2Hash;Assembly2.dll Version=2:Culture:MVID2:ScriptName3Hash

If you're already using ToolkitScriptManager and want to start using CombineScriptsHandlerUrl, but don't want to have to modify a bunch of ASPX pages to add the new property, you can take advantage of the fact that ToolkitScriptManager is now decorated with the Themeable attribute and can be customized by a .skin file as part of ASP.NET's Theme/Skin support. Adding CombineScriptsHandlerUrl to all the pages of the Toolkit's SampleWebSite was easy - I just added a ToolkitScriptManager.skin file to the existing web site theme and used the code <ajaxToolkit:ToolkitScriptManager runat="server" CombineScriptsHandlerUrl="~/CombineScriptsHandler.ashx" /> to set CombineScriptsHandlerUrl for the entire site.

ToolkitScriptManager is a handy way to enhance a web site with the AJAX Control Toolkit and it's gotten even better with the 10618 release of the Toolkit. We think ToolkitScriptManager offers some pretty compelling enhancements and we use it for all the AJAX Control Toolkit's sample content. We encourage anyone who's interested to give ToolkitScriptManager a try and see how well it works for them. As always, if there are any problems, please let us know by posting a detailed description of the problem to the AJAX Control Toolkit support forum.

Happy script combining!!

Tweaks and improvements by popular demand [AJAX Control Toolkit update!]

Delay — Tue, 19 Jun 2007 03:59:00 GMT

A short while ago we made available the 10618 release of the AJAX Control Toolkit. This release addresses a handful of user-impacting issues introduced by changes in the recent 10606 release and identified by the user community in the support forum and online issue tracker. Significant changes always have the risk of introducing problems so we do our best to find and fix them all before releasing. But for things that manage to sneak through, a targeted follow-up release is often a good way to fix annoyances quickly.

The release notes from the sample web site detail the improvements in the new release:

General fixes:

Tabs: Resolved NamingContainer issues so that FindControl works as expected in Tabs.

ToolkitScriptManager: Shorter combined script URLs and new HTTP handler support for generation of combined script files.

Dependencies: Removed explicit reference to VsWebSite.Interop.dll and stdole.dll. They will not be automatically included in the web configuration files by Visual Studio.

FilteredTextBox: Navigation, Control and Delete keys work fine in all browsers.

Localization: Turkish, Dutch, and Traditional and Simplified Chinese language support added.

As always, it's easy to sample any of the controls right now (no install required). You can also browse the project web site, download the latest Toolkit, and start creating your own controls and/or contributing to the project!

If you have any feedback, please share it with us on the support forum!

PS - Last week I blogged an overview of the ToolkitScriptManager introduced in the 10606 release. ToolkitScriptManager has gotten even better in this release, and I'll be writing more about it later this week!

Script combining made easy [Overview of the AJAX Control Toolkit's ToolkitScriptManager]

Delay — Tue, 12 Jun 2007 01:39:00 GMT

Introduction

The 10606 release of the AJAX Control Toolkit includes ToolkitScriptManager, a new class that derives from the ASP.NET AJAX ScriptManager and performs automatic script combining.

What is meant by "script combining" and why is it desirable?

ASP.NET AJAX Behaviors are typically implemented by JavaScript (JS) files that are downloaded by the browser as part of the web page's content/resources (like CSS files, images, etc.). Each JS file typically contains a single Behavior, so if a web page uses lots of Behaviors, it's going to download lots of Behavior JS files. The cost to download a single JS file is fairly minimal, but when there are many of them on a page, the serialized nature of Behaviors (later ones may depend on earlier ones and can't be loaded until the earlier ones have finished) means that it may take a bit of time for all the JS a page needs to download to the user's browser. The time in question is typically on the order of milliseconds, but every little bit helps when you're looking to give users the best possible experience!

Script combining is beneficial because fewer JS files means fewer request/response operations by the browser - which translates directly into quicker page load times for users and less load on the web server. Furthermore, there will be less network traffic because the HTTP headers associated with each unnecessary request/response operation don't need to be transmitted (saving around 750 bytes for each combined script).

At the extreme, one could combine all (~40) the Behaviors in the Toolkit into a single, monolithic JS file (either manually or as part of the build process) and always send that file to the browser. While there are certain benefits to this, we chose not to do so for two main reasons: 1) the ASP.NET AJAX framework the Toolkit builds upon is an object-oriented framework and it's beneficial to maintain the mental/physical separation that comes from keeping each behavior isolated and 2) any page that used any part of the Toolkit would be forced to download the entire set of scripts in the Toolkit.

ToolkitScriptManager gives us the best of both worlds by combining exactly the relevant JS files used by each page into one file so the browser downloads only what's necessary for each page. ToolkitScriptManager's script combining is more than a simple concatenation of all the script files in the Toolkit; it's a dynamic merge of only the scripts that are actually being used by a page each time it's loaded by the browser. If a page has an ASP.NET AJAX UpdatePanel on it and additional scripts need to be sent as part of an async postback, then ToolkitScriptManager will automatically generate a combined script file containing only those scripts that the browser hasn't already downloaded.

ToolkitScriptManager automatically compresses the combined script file if the browser indicates it supports compression - achieving slightly better compression in the process because most adaptive dictionary-based compression techniques (like HTTP's GZIP and Deflate) tend to compress data better in one chunk than in multiple chunks (because the dictionary doesn't keep getting reset). The combined script file is cached and reused by the browser just like the corresponding script files would have been if ToolkitScriptManager weren't being used.

Basically, script combining effortlessly creates faster loading web pages - and happier users by extension!

How do I use it?

Simple: Just replace <asp:ScriptManager ... /> with <ajaxToolkit:ToolkitScriptManager ... /> in your ASPX page and you're done! (Of course, if you're not using the default namespaces "asp" and "ajaxToolkit", you'll need to substitute your own namespaces.) The scripts in the AJAX Control Toolkit are already enabled for combining, so it's really that easy!

ToolkitScriptManager derives from ScriptManager, so it can be substituted trivially. Configuration-wise, it exposes a single new property beyond what ScriptManager already has: bool CombineScripts. The default value of "true" means that scripts will be automatically combined - specifying the value "false" disables the combining. (Alternatively, just switch back to ScriptManager for the same result.)

How do I enable combining for my custom Behavior's scripts?

As a security precaution to prevent malicious users from taking advantage of ToolkitScriptManager to access embedded resources from unrelated DLLs, the new assembly-level ScriptCombine attribute must be used to indicate that a particular assembly/script is allowed to take part in the script combining process. By default, none of the scripts in an assembly without the ScriptCombine attribute will take part in script combining. Adding the ScriptCombine attribute to an assembly indicates that all of its scripts can take part in script combining and ToolkitScriptManager will automatically include the relevant ones when generating a combined script file. For finer control over individual scripts in an assembly, the ScriptCombine attribute exposes an ExcludeScripts property and an IncludeScripts property - both are comma-delimited lists of individual script files. As stated, when neither property is specified, the default behavior is that all scripts are combinable. Once the IncludeScripts property is set, only the scripts explicitly specified by it are combinable. The ExcludeScripts property excludes any listed scripts from combining (whether or not IncludeScripts is set). Of course, most people will simply add the ScriptCombine attribute to their assembly and the default behavior does what they want. (As mentioned above, Toolkit scripts are already enabled for script combining.)

How do scripts actually get combined? [Technical]

Script combining is a two-stage process.

The first stage takes place during the normal ASP.NET page lifecycle when ToolkitScriptManager overrides ScriptManager's OnLoad method to initialize its state and its OnResolveScriptReference method to find out when script references are being resolved. The initialization code in OnLoad consists of adding a HiddenField to the page and using it to track which scripts have already been loaded by the browser. The handling of OnResolveScriptReferences is a little more involved: the script reference is checked for combinability (i.e., does the assembly's ScriptCombine attribute allow the script to take part in script combining) and the script reference is changed to point to the URL of a combined script file. In this manner, all scripts that are part of the same combined script file get the same URL and the ScriptManager class outputs that URL to the page exactly once. Notably, because scripts may have a strict ordering, the presence of an uncombinable script in the middle of combinable scripts will result in two combined script files being generated (the first consisting of the scripts coming before the uncombinable script and the second consisting of the scripts after it).

The URL of the combined script file is currently of the form: .../Page.aspx?_scriptcombiner_=;Assembly1.dll Version=1:MVID1:Script.Name.1.js:Script.Name.2.js;Assembly2.dll Version=2:MVID1:Script.Name.3.js. What this means is that the ASPX page itself is referenced with the special request parameter "_scriptcombiner_" and a semicolon-delimited list of assemblies with a colon-delimited list of the required scripts from each of them. The strong name of the assembly is used to avoid potential confusion if multiple versions of an assembly are present and the ModuleVersionID (MVID) is used to ensure that any changes to the assembly itself automatically invalidate all combined script files that reference it. In this manner, recompiling one of the assemblies contributing to a combined script file will cause the new scripts to be downloaded by the browser next time the page is loaded.

The second stage of script combining takes place when the page is referenced with the "_scriptcombiner_" request parameter. ToolkitScriptManager overrides OnInit (one of the first parts of the page lifecycle) and uses that opportunity to generate the combined script file based on the value of the request parameter, outputs the combined script file to the browser, and stops further processing of the page lifecycle. Of note, the cache settings of the combined script file are set to the same values that the individual script files would have had if ToolkitScriptManager weren't being used and the combined script file is automatically compressed according to the browser's wishes. Similarly, any localized script resources for a script file that is in the process of being combined are loaded and sent to the browser as part of the combined script file. After all combined scripts are output, ToolkitScriptManager appends a small bit of script to the end of the file to update the page's HiddenField with the scripts that have just been added. In this manner, any additional scripts added during an async postback are automatically tracked by the page and subsequent async postbacks will know exactly which scripts have already been loaded by the browser.

Why piggyback a request parameter on the same page instead of using an IHttpHandler? [Technical]

ScriptManager uses ScriptResourceHandler (an IHttpHandler) to serve (uncombined) scripts, so it's natural to wonder why ToolkitScriptManager wouldn't do the same. The reason is that the AjaxControlToolkit DLL is often run in partial trust scenarios where it couldn't add such a handler to the system itself - and because we don't want people to have to modify their web.config file just to enable script combining. By making use of the same page for serving combined script files, ToolkitScriptManager offers a seamless experience that's simple to configure, simple to manage, and that works even for folks who don't have control over the web server that's hosting their content.

Are there any tradeoffs when switching to ToolkitScriptManager?

There are no significant tradeoffs that we know of, but there are a couple of implications it's good to be aware of. For one, the current combined script URL format is currently pretty verbose and can lead to unusually long URLs. While this hasn't been a problem so far, it will be easy to change the format in the future (with no impact to users) and we're already considering ways of doing so. Another thing to be aware of is that reusing the page to serve the combined script file means that there is some additional server processing that happens before/during the OnInit stage of the page lifecycle when processing a combined script file. (Though the additional work here is offset by the savings of not having to serve multiple JS files.) Again, this hasn't been an issue, but it's something to keep in mind if things behave differently after adding ToolkitScriptManager to a page.

So just how risky is it to switch to ToolkitScriptManager?

That's a loaded question [ :) ], but it's informative to note that all AJAX Control Toolkit sample pages (including the sample web site, automated tests, manual tests, etc.) have been converted over to use ToolkitScriptManager with only one issue: The Slider's SliderBehavior.js script uses a fairly obscure feature enabled by the PerformSubstitution property of the WebResource attribute that allows <%= WebResource/ScriptResource %> tags to be embedded in JS files and get resolved before the script is sent to the browser. This behavior isn't currently supported by ToolkitScriptManager (it will throw an informative Exception if it detects the presence of this construct), so the ExcludeScripts property of the ScriptCombine attribute on the AjaxControlToolkit DLL has been used to exclude the SliderBehavior.js file from being combined.

Summary

ToolkitScriptManager works seamlessly in every page of the AJAX Control Toolkit, so we encourage folks to give it a try if they're interested in the benefits it offers! As always, if you encounter any problems, please let us know by posting a detailed description of the problem to the AJAX Control Toolkit support forum.

Happy script combining!!

Fixes and features by popular demand [AJAX Control Toolkit update!]

Delay — Thu, 07 Jun 2007 03:28:00 GMT

Earlier today we made available the 10606 release of the AJAX Control Toolkit. This release focused on addressing many of the most popular bugs and work items identified by the user community in the support forum and online issue tracker. We've also added some new functionality to the Toolkit that really improves the user experience for page authors and consumers alike!

The release notes from the sample web site detail the improvements:

General fixes:

Design Mode support:

Tabs designer: Tabs control can be configured in the designer.

PageMethods in code-behind: Extenders that consume web services can now have PageMethods added to code-behind automatically when using the designer. A repair mode fixes existing PageMethods with incorrect signatures.

Control icons: Toolkit controls have more meaningful icons that show up in the Visual Studio Toolbox when the Toolkit DLL is added to it.

Dynamic context: Toolkit extenders that consume web services can now pass additional context beyond what is used by the default web service signature.

Validators and Toolkit extenders: Extenders that target TextBoxes with ASP.NET validators attached to them no longer interfere with the validation process.

Animation support: Toolkit controls that build on top of PopupBehavior now have generic animation support built in.

Script combiner: When the ToolkitScriptManager is used, Toolkit scripts are downloaded in a single, common JavaScript file instead of multiple files. This allows for faster downloads and fewer roundtrips. The combined file is generated dynamically depending on the controls being used on the page. All Toolkit sample pages use this new functionality.

Events support: Toolkit controls fire events for core actions. This is in part to make plugging in animation easier and also to allow users to hook into the various Toolkit controls' behaviors and perform custom actions.

Bug fixes: This release includes fixes for over 120 issues tracked in the Toolkit Issue Tracker representing over 750 user votes.

Accessibility fixes: Slider and AutoComplete have support for high contrast and some controls like AutoComplete, NumericUpDown, CascadingDropDown and DynamicPopulate which issue XmlHttpRequests update a hidden DOM element to automatically refresh the JAWS screen buffer to reflect new data.

Control updates:

MaskedEdit extender works well with the Calendar extender and the ValidatorCallout extender when targeting the same TextBox.

AutoComplete supports scrolling in the fly-out, multi-word, first word default selection and it has animation built into it.

ModalPopup fix for most common scenarios involving absolute and relative positioning.

NumericUpDown has new Minimum and Maximum properties to restrict the range of numbers allowed.

Visual Studio Codename "Orcas" support:

The Toolkit DLL works with ASP.NET AJAX Orcas Beta 1 DLLs and there are no breaking changes.

For more details about the Tabs designer, web service design-time enhancements, and script combining (along with some pretty pictures!), check out Shawn Burke's release announcement.

If you have any feedback, please share it with us on the support forum!

PS - The public sample site hasn't been deployed quite yet (real soon now!), but the new Toolkit bits are up on CodePlex, so feel free to get them and start using them!

Toolkit patching made easy [Announcing the AJAX Control Toolkit Patch Utility]

Delay — Fri, 13 Apr 2007 21:35:00 GMT

We've just made available the AJAX Control Toolkit Patch Utility, a simple ClickOnce application that makes it easy for *anyone* to contribute fixes to the AJAX Control Toolkit!

Background: We have a very active user community that's using the Toolkit in lots of ways we never imagined. Sometimes people come up with better ways of doing things and occasionally they bump into a new issue we didn't know about. When questions show up on the support forum, it's great to see someone follow up with a change to the Toolkit that resolves the issue. These community contributions are fantastic - we always try to add a pointer to the associated work item for the issue so we won't forget about it. However, there is a fair amount of effort involved in merging such fixes into the Development branch of the source code and that effort can delay the incorporation of proposed changes. The new Patch Utility is designed to streamline the process so it will be easier for people to contribute fixes and easier for the Toolkit team to incorporate them into the next release of the Toolkit. By making the process simpler and enabling the inclusion of more community fixes, everyone benefits by having a better Toolkit that they're less likely to have trouble with!

How patching works: The AJAX Control Toolkit Patch Utility Guide contains all the details - along with screenshots that walk through everything. The process itself is pretty simple. Once a Toolkit user identifies a problem, he/she runs the Patch Utility in "Create a Patch" mode which walks through the steps of downloading the latest Development branch of source code for the Toolkit. The user makes whatever changes to the Toolkit are necessary to fix the problem and alters the automated test cases to verify the new behavior. Then the user runs the Patch Utility again in "Prepare Patch for Submission" mode which collects the changes that were made, gives the user an opportunity to review them in a file differencing tool, and generates a compact ZIP archive containing the user's patch. The user attaches the ZIP file to the existing work item that corresponds to the issue he/she fixed and that's it!

What happens next: On the back end, we have a process running which periodically looks at outstanding work items for new patches. When a new patch is found, a set of "check-in-able" changes is automatically created for that patch. What that means for the Toolkit team is that it's easy for any of us to review the patch, merge it with the very latest version of code in the Development branch, test it on our machines, and check the patch in for inclusion with the next Toolkit release!

What changes make good patches: Bug fixes and minor enhancements to existing code make great patches because the overall amount of change is small and the effect of the change is fairly self-contained and easily testable. On the other hand, broad changes like the addition of an entirely new control or the refactoring of a significant chunk of code would not make good patches due to the widespread effects of such changes (we have a different process in place for such things; email us if you want to add a new control).

The Patch Utility enables anyone to make fixes to the Toolkit - if you're a Toolkit user and you've got a fix floating around on your machine, please use the AJAX Control Toolkit Patch Utility to submit it! And if you have any suggestions for things we can improve please send your feedback to us!

AutoComplete++ [How to: Create a multi-word auto-complete text box]

Delay — Sat, 31 Mar 2007 02:39:00 GMT

By default, the AJAX Control Toolkit's AutoComplete extender doesn't have a notion of "words" and will try to auto-complete whatever text is currently in the text box, treating what's there as a single "word". One request that has come up a few times was for the ability to auto-complete multiple words individually. According to the comments of that work item, it looks like someone's made a set of proposed changes to do just that! It's great to have such an involved user community!! (Please note: The work item comments suggest those changes don't work in all browsers.)

One thing I'd been meaning to do was write a quick sample of how to get reasonably good multiple-word auto-complete without making any modifications to the released AutoComplete extender. In other words, you can use the latest official Toolkit release (10301 in this case) and get some nice multi-word completion today. The key observation here is that the Web Service used to provide the list of candidate words has all the information it needs to do multi-word completion as well:

The complete code for the sample page is included below for anyone to look at or modify for their purposes. A few notes about the code:

The example was written to be simple, not efficient. The goal is to demonstrate the idea as plainly as possible, so there's no focus on performance.
The code works by auto-completing the last "word" of input and then populates the list of candidates with the resulting words and the preceding text.
All comparisons are case-insensitive so the user can type however they want.
In a real-world application, the list of candidate words would probably be retrieved from a helper function, a database, etc..

Here's the complete ASPX file:

<%@ Page Language="C#" %>

<%@ Register Assembly="AjaxControlToolkit" Namespace="AjaxControlToolkit"
    TagPrefix="ajaxToolkit" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script runat="server">
    [System.Web.Services.WebMethod]
    [System.Web.Script.Services.ScriptMethod]
    public static string[] GetCompletionList(string prefixText, int count)
    {
        // Fetch and sort the list of available completion words
        string[] allWords = "AJAX Control Toolkit AutoComplete auto automatic".Split(' ');
        Array.Sort(allWords);

        // Split input into completed words and prefix characters for the current word
        // Match on the current word and return candidate list including completed words
        // Ex: "he" -> "" and "he..."
        // Ex: "hello there th" -> "hello there " and "th..."
        string completedWords = "";
        string prefixChars = prefixText;
        int lastSpace = prefixText.LastIndexOf(' ');
        if (-1 != lastSpace)
        {
            completedWords = prefixText.Substring(0, lastSpace + 1);
            prefixChars = prefixText.Substring(lastSpace + 1);
        }

        // Create the completion list by searching for prefix matches
        System.Collections.Generic.List<string> completionList =
            new System.Collections.Generic.List<string>();
        foreach (string word in allWords)
        {
            if (word.ToUpperInvariant().StartsWith(prefixChars.ToUpperInvariant()))
            {
                completionList.Add(string.Concat(completedWords, word));
            }
        }

        // Return the completion list
        return completionList.ToArray();
    }
</script>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>Multi-Word Auto-Complete</title>
</head>
<body>
    <form id="form1" runat="server" onsubmit="return false;">
        <asp:ScriptManager ID="ScriptManager1" runat="server" />
        <asp:TextBox ID="TextBox1" runat="server" Width="300" />
        <ajaxToolkit:AutoCompleteExtender ID="AutoCompleteExtender1" runat="server"
            TargetControlID="TextBox1" ServiceMethod="GetCompletionList"
            MinimumPrefixLength="0" />
    </form>
</body>
</html>

Enjoy!

Toolkit talk two-fer! [Spoke at the ASP.NET Connections conference]

Delay — Tue, 27 Mar 2007 01:16:00 GMT

Earlier today I presented two talks about the AJAX Control Toolkit at the ASP.NET Connections conference in Orlando, Florida: AMS305: ASP.NET AJAX Control Toolkit: See How to Take Advantage of the ASP.NET AJAX Control Toolkit and AMS304: ASP.NET AJAX Control Toolkit Unleashed: Creating Rich Client-Side Controls and Components.

The content for these talks was based on stuff I've previously presented at TechReady4 in February and ASP.NET Connections in November of last year. However, this time around I was able to go into quite a bit more detail because I had over twice as much time to speak and do demos. The introductory AMS305 talk took the ImageFlix sample I've used before and expanded on it to demonstrate the Toolkit's new support for ASP.NET Skins/Themes and advanced animations followed by a quick walkthrough of what to do when things don't work like you'd expect (demonstrated here by adding a DropShadow to the popup panel). The more advanced AMS304 talk used an updated FontSize extender demonstration like the one that was demonstrated at the November ASP.NET Connections and included an overview of working with the Toolkit project, highlighting the automated testing framework and new localization support. Overall, there are about 15 completely new slides with fresh content, covering topics such as localization, automated testing, and more.

I've attached the slide decks and the demo content for both talks to this post so that anyone who's interested can have a look at the slides or play around with the demos.

I hope those of you who attended today enjoyed the talk and learned more about the Toolkit - it was great to have an opportunity to spend time with you!

Lost (Sk)in Translation [AJAX Control Toolkit update!]

Delay — Fri, 02 Mar 2007 15:28:00 GMT

A short while ago we made available the 10301 release of the AJAX Control Toolkit. With this release, we managed to add some great core functionality, a couple of new controls, and a bunch of bug fixes for popular issues (as identified by our user community in the support forum and online issue tracker).

The 10301 release includes two new controls:

ListSearch (by contributor Damian Mehers) - A handy enhancement to ListBox/DropDownList controls that allows the user to select items by typing the first few characters
SlideShow (by our own Kirti) - A visually pleasing slide show of automatically sized images and captions with optional automatic looping or manual control

We also managed to add three pieces of core functionality that users have been asking for:

Localization support - The Toolkit now has an infrastructure for localizing the text in JavaScript files using the standard ASP.NET/AJAX support for resource files. There are placeholder files for the following 14 languages: Arabic, German, English, Spanish, French, Hebrew, Hindi, Italian, Japanese, Korean, Portuguese, Russian, Chinese (Simplified), and Chinese (Traditional). Complete localization of all strings hasn't been done yet, but our most popular request by far is for the string "Today:" at the bottom of the Calendar's popup - and that has already been localized to all of the above languages. Just set your system/browser's language settings to one of the supported languages and visit the Calendar sample page for a demonstration.
JavaScript comment/whitespace stripping - People are always interested in keeping the download size of their pages as low as possible, and the Toolkit goes the extra mile to help. When compiled in "Release" mode (as the official releases on CodePlex always are), all of the JavaScript files in the Toolkit automatically have all comments and unnecessary whitespace removed. Ted, the author of this functionality, was careful to adhere to the ECMA-262 ECMAScript Language Specification, so the modifications are both safe and effective.
ASP.NET Theme/Skin support - Central control is usually best, so it's nice to be able to use ASP.NET's theme/skin support to specify properties for controls across an entire web site in one central location. Toolkit controls didn't used to be skinnable (i.e., support the SkinID property) but now they are, so go ahead and start skinning your site. In fact, we used this new ability to style the CollapsiblePanels that we use for descriptions/properties/known issues on every sample page.

And, with the help of our contributors, we fixed a bunch of bugs along the way...

We hope you like the new release!!

Recall that you can sample any of the controls right now (no install required). You can also browse the project web site, download the latest Toolkit, and start creating your own controls and/or contributing to the project!

If you have any feedback, please share it with us on the support forum (or email me)!

Toolkit talk, take two [Spoke at the TechReady4 conference]

Delay — Fri, 09 Feb 2007 06:43:00 GMT

Earlier today I presented the DEV304: ASP.NET AJAX Control Toolkit Unleashed: Creating Rich Client-Side Controls and Components session at Microsoft's TechReady4 conference here in Seattle. TechReady is a Microsoft-only conference that non-Redmond-based employees attend to get an opportunity to meet with product team members (typically Redmond-based) and catch up on all the new technology each year. Most of the session content is Microsoft-only, but because the presentation I gave today had no private information, I'm posting the (sanitized) slide deck and demos here for everyone to use (note: the attachment is at the bottom of this post).

If you saw the content for my ASP.NET Connections talk a few months ago, the slide content for today's TechReady4 talk was very similar. The first demo was identical and the second (new) demo was just a quick overview of the sample web site that comes with the Toolkit. However, the third demo was completely new and demonstrated how to encapsulate existing script into a new Toolkit control. For demonstration purposes, I took a simple web page with a WPF/E (February CTP) control (the use of which requires two <script>/src tags and a <script>/code block) and showed how to wrap that all into a single "one-liner" Toolkit component which can be more easily used/maintained/added to a page. Those of you who are paying close attention will realize that I took my inspiration from a similar effort by my manager, Shawn Burke - though I wrote all my demo code from scratch so I'd be more familiar with it. :) The final result is a pretty handy way of handling WPF/E controls and folks are welcome to use it however they want!

I hope those of you who attended today enjoyed the talk and learned more about the Toolkit - it was great to have an opportunity to meet with you!

PS - We're always looking for more contributors and additional control ideas, so please let me know if you want to contribute!