Hello Kirti : Toolkit

Community Contributions in Toolkit release 10920

kirtid — Mon, 24 Sep 2007 10:19:26 GMT

When I wrote my previous blog post I was in a rush to make the release announcement because we had a lot of users waiting eagerly for it. But I did not get a chance to thank our users who contributed patches to the Toolkit and made the release a success....(read more)

SlideShow navigation

kirtid — Mon, 17 Sep 2007 08:10:00 GMT

I have written a simple example that uses the SlideShow extender and demonstrates some of its cool features. The sample... provides additional context to the user by showing the previous and next slides by hooking into the 'slideChanging' event that SlideShow...(read more)

Toolkit showcase

kirtid — Fri, 07 Sep 2007 09:44:00 GMT

We are compiling a list of websites to showcase on the Toolkit page that is a part of the ASP.NET website . Details on how the page will end up looking like have not been fleshed out yet. Just like this ASP.NET AJAX showcase displays interesting websites...(read more)

Toolkit update

kirtid — Fri, 07 Sep 2007 04:02:00 GMT

It has been a while since we released so we would like to update our users with the latest happenings in the Toolkit world. Our next release is scheduled to be around the 14th of September . What will it include? New test framework and tests: It will...(read more)

Toolkit support for .NET Framework 3.5 and Visual Studio 2008 Beta2

kirtid — Fri, 27 Jul 2007 05:39:00 GMT

The next wave of Visual Studio products coming out from the Developer Division in Microsoft promises a richer development experience than its predecessors. Features that deserve special mention since they are particularly relevant to the Toolkit are Javascript...(read more)

How to make localization in the Toolkit work for you?

kirtid — Fri, 29 Jun 2007 05:11:00 GMT

FAQ # ...: Why does the Toolkit add resources binaries to a website's bin directory? To explain the motivation behind this I have put up a wiki on our CodePlex site that details how to make the most of the Localization features without getting overwhelmed...(read more)

Lather, rinse and release

kirtid — Tue, 19 Jun 2007 06:17:00 GMT

We had a Toolkit release last week and our product support medium, the forums , gave us instant feedback. So what happens when issues in the Toolkit prevent our customers from taking full advantage of it and block their core scenarios? We do not have...(read more)

Mind your language!

kirtid — Tue, 12 Jun 2007 19:38:00 GMT

The Toolkit supports localization since the 10301 release. The work involved included basic infrastructure and translations for the string "Today" used by the Calendar control in 14 languages. With the Toolkit Patching Utility in place we are receiving...(read more)

Toolkit: New and improved!

kirtid — Thu, 07 Jun 2007 03:06:00 GMT

The latest version of the Toolkit is out. Try it out now. What's so great about this release? This release is particularly special since we had very active Toolkit contributor participation. We also got contributions in the form of patches that allowed...(read more)

Cascading AutoComplete

kirtid — Thu, 17 May 2007 10:52:00 GMT

We have received a lot of feedback from users about not being able to pass additional information to the AutoComplete webservice which limits their usage of the extender. We decided to absorb that input and add support to all extenders that issue XmlHttpRequests...(read more)

Using UpdatePanels with ModalPopups

kirtid — Fri, 04 May 2007 02:13:00 GMT

One of the most frequently asked questions on the Toolkit forums and at MIX after Shawn's demo was how to get UpdatePanels to work right with ModalPopups. The trick is to understand that the ModalPopup extender attaches itself to more than just the TargetControl and PopupControl. If you include the OK and Cancel buttons inside the ModalPopup Panel in an UpdatePanel, make sure you include the extender declaration in it as well. If you do not, once a postback occurs the extender will not reinitialize the handlers and you will get null references. Also, if buttons inside the ModalPopup Panel are set to be OK and Cancel buttons on the ModalPopup Extender, then their sole purpose is to close the Popup Panel and run their respective scripts if any have been set. They will not perform postbacks or execute any other client side handlers since the ModalPopup prevents the event from propagating up.

I have attached a sample page that demonstrates three simple scenarios with ModalPopups and UpdatePanels.

ModalPopup with an UpdatePanel inside its Popup Panel: Make sure that the OK and Cancel buttons are not inside the UpdatePanel otherwise the handlers will be rendered useless on postback.
UpdatePanel that contains a ModalPopup Extender and its Popup Panel: Clicking OK or Cancel still does not cause the postback since those buttons are tied to client side handlers. Clicking on any other control will cause the server side handlers to kick in. Since the extender declaration is inside the UpdatePanel, the asynchronous postback causes the ModalPopupBehavior to be reinitialized correctly and any client side handlers are setup again when the request is completed. So if you would like to postback every time the user clicks OK or Cancel, just don't set those properties on the extender. The Modal Popup Panel closes on postback as desired since the entire popup is inside an UpdatePanel.
What if that Popup Panel in # (2) contains an UpdatePanel: Specify the triggers that will cause the outer panel to update and allow the UpdatePanel inside the ModalPopup to operate on its own terms. This time the ModalPopup Panel does not close on postback triggered from within it because the trigger for the outer panel is specifically set to be a separate button.

It is a good idea to design the page without UpdatePanels in mind. When writing the page place UpdatePanels when the rest is done. Once you have the page setup, determine locations in your page that need to be asynchronously updated and the controls that should act as triggers to perform that operation and then appropriately place UpdatePanels with the correct triggers and UpdateMode property set. With extenders it is important that you take into consideration not just the controls targetted by the extender but any others which it hooks into to provide additional functionality.

This post should evolve as I get more feedback and I will update the sample accordingly as well. I hope this helps.

Silverlight at the end of the tunnel

kirtid — Fri, 04 May 2007 00:22:00 GMT

I was in Las Vegas this week attending the MIX' 07 conference along with the rest of the Toolkit team. My team mates, David Anson and Ted Glaza worked on the keynote demo that Scott Guthrie presented. The demo was written in managed code using the alpha version of the Silverlight platform that Microsoft showcased at MIX. It is a cool airline application composed of three core controls, Calendar, FlightPicker and Map. The source code is available for download from David's blog.

Silverlight will be a big leap in terms of the way we perceive the web. Essentially, with the managed code support, one no longer needs to be a web developer to write rich and interactive web applications. There is no need to worry about javascript, understand browser differences or css incompatibilities. It is all abstracted away from the developer who can focus on the end scenario without being distracted by these issues. All there is to see is XAML, XAML and more XAML and of course CSharp. I am up for that any day if I can get away from javascript. Why? Static language, with rich compiler support, intellisense, debugging support and a wide array of .NET apis to build on top of - need I say more? Our next project may have a lot more to do with Silverlight. Will it be a Silverlight Control Toolkit? May be. If you have ideas or suggestions around it do send me an email or leave a comment.

Accessibility support in the Toolkit

kirtid — Fri, 20 Apr 2007 08:33:00 GMT

Accessibility has long been one of the most neglected aspects in the software development process. Those who do take it up, do so because they wish to secure a customer who has government compliance clauses. Getting resources assigned for accessibility work is a tough job with few takers. We, the Toolkit team, think it is a fulfilling and worthy task and do not want to deprive users with disabilities of the Toolkit's coolness!

Although accessibility on the client has been pretty stable in terms of Assistive Technologies(AT) and platform support, web accessibility remains in its nascent stages with the web redefining itself. W3C is working on the WCAG 2.0 draft which will be the second attempt to flesh out web accessibility guidelines in the wake of the AJAX movement. Its charter is to deliver a web accessibility standard that will guide web developers to author semantically correct web sites which will communicate better with AT devices.

We eagerly await the industry standard that both web technologies and AT devices will comply with. However, till then the Toolkit controls need to be as accessible as possible to everyone, including users with disabilities within the current scope of accessibility guidelines. To achieve that goal we have an Accessibility Plan in place and hope to deliver support one issue at a time. We have already started making efforts to fix issues as we find them and we have a lot more in our Issue Tracker that we would like to take up soon.

So join us in your efforts to make the Toolkit more accessible. We are not Accessibility experts but working on it, so if you have accessibility domain knowledge, we see a potential partnership here! How can you help? Know about issues in Toolkit that could be changed to improve the accessibility experience, send us an email, post it on our forums or simply create a work item.

Some useful links:

Section 508 is the US Law that states that all software should not discriminate against users with disabilities by disallowing them access to features that normal users have and prevent them from making the best use to operate effectively.
European policies are also in place to ensure that the software is accessible to all.
Juicy Studios is a site which provides guidelines on authoring accessible websites
Learning the world is very good blog on web standards and accessibility

Toolkit for all!

Yours modally

kirtid — Mon, 09 Apr 2007 04:43:00 GMT

I can see a gray Seattle skyline as I stare out of my window on what should have ideally been a nice Sunday evening in spring time. It is pouring buckets and the view is hazy, reminding me of the html hidden behind the gray modal popup background. I am unable to get out of my apartment and hit downtown before the showers stop because winter seems to be stuck modally in Seattle, just as I am unable to access the webpage till I dismiss the popup. Does it sound like I am obsessed with the ModalPopup? Well, not exactly. I am trying to add some more functionality to it and am stuck, unable to proceed and not liking it, hence the analogy to get the message across.

The ModalPopup is already a loaded extender. The behavior encapsulates PopupBehavior, DragBehavior and DropShadowBehavior. Having made the ModalPopup draggable, I thought it would be interesting to make it resizable as well. Although, adding the ResizableControlBehavior problem turned out to be harder than I had expected.

Here is a brief overview on how the ModalPopup works.

TargetControl: The control whose click event causes the popup to show.

PopupControl: The popup that will be shown modally.

If DragDrop and DropShadow functionalities are turned on the ModalPopup, the markup will be arranged in the following way which is quite tedious with the positioning of all elements needed to be handled correctly.

<OuterContainerDiv> // created by the ModalPopupBehavior

<PopupControl> // what the user passes as the Popup

<DragHandleDiv /> // control that the user would like to see as the DragHandle

</PopupControl>

<DropShadowDiv /> // DropShadow div created by the behavior

</OuterContainerDiv>

What do I have so far? The ResizableBehavior has been added to the PopupControl and tracking is turned on, on the DropShadow so that it gets redrawn when PopupControl is resized. Overflow is set to "auto" on the PopupControl. The problem is that the resize handle gets hidden behind the scroll bars, which means that I need to scroll to bring it into view before I can resize it. If only the resize handle could be placed right at the intersection of the two scroll bars!

A better, but more long winded option would be to write a ResizableScrollBar extender that adds custom scroll bars to panels if necessary just like the built-in html overflow support and allows the panel to be resized as well. In which case the user would have more control on the resize handles and scroll bars. The Slider behavior could be repurposed to be an html scroll bar perhaps and the extender would have to perform the calculations to scroll properly. Any other ideas to dismiss this "modal" issue?

Feature complete AutoComplete extender? Not yet.

kirtid — Fri, 30 Mar 2007 01:48:00 GMT

I just finished making a bunch of changes to the AutoComplete extender in the Toolkit. You can now css style the AutoComplete extender and make it as fancy as you would like it to be, well, as long as the completed content is text, which is what we support right now. But it is still pretty straightforward and meets most common scenarios. And hey, it is free! So you can download the source code at this very moment and start playing with it, even deploy it right away. These changes will be part of our official release within the next couple of months but there is nothing stopping you from using the latest bits. If you run into issues, please post them on our forum or report a bug.

The autocomplete flyout is a custom menu and we need to handle keyboard and mouse events explicitly. We also have one more task at hand which is making the extender accessible, which means that the menu html needs to be keyboard usable, use semantic html and be in the right dom order to start with. There is more to AJAX accessibility than that of course; as you delve deeper to add regular features which need to be implemented to meet core scenarios you will always discover that they need nasty workarounds to ensure accessibility and cross browser support. The browser as an application platform is not fun to work with given its eccentricities.

Anyways, back to the accessibility features...To achieve DOM order correctness, the autocomplete flyout element is now inserted right after the textbox; which means that it will be in the screen reader's list to read out loud next. The other issue is keyboard support, which was already present in the extender but needed to be tweaked to work with scrolling. In cases such as this one, it is most useful to operate as closely as existing menu controls to avoid any learning curve and introduce behavior that is not very intuitive which just means more work to be done in the extender itself. The keyboard support now handles scrolling which I compute based of the scrollHeight, scrollTop and clientHeight properties on the flyout element. I was attempting to use scrollIntoView to avoid performing the computations myself but it was based off the window and it resulted in the whole window scrolling when I hit the down/up arrows in the flyout. Bertrand Le Roy, a developer from the ASP.Net AJAX team and my accessibility cohort, recommended that I do it myself and that turned out to be the safest bet, worked across browsers and was under my control. The third thing was semantic html which was an almost easy fix, but one which will go a long way in making the autocomplete flyout useful for people with disabilities. The flyout markup is now an unordered list and that helps clarify the purpose of the element to the user. An additional accessibility feature came in as a freebie. I earned it by making the flyout css stylable, support in High Contrast mode. The color and background of the flyout can be friendlier in that scenario. Although, I have to admit that the colors I have chosen on the Toolkit sample website autocomplete menu will not work very well in high contrast. My reasoning? I was lazy to find colors that worked in normal mode in all browsers and that would work in high contrast as well.

What about localization? We already support localizing strings in the Toolkit but with css styling in, left-to-right and right-to-left settings are a piece of cake, chocolate cake perhaps...better and better!

So the AutoComplete extender supports theming as do all extenders in the Toolkit, is xhtml compliant, has international support, is almost accessible and very stylable. What's next?

Additional keys support like "home", "end", left/right arrows
Ability to pass additional data to the webservice; currently you can only pass the text in textbox and the number of suggestions you would like
Custom return types? Like pictures in the list? Wow, that would be nice but not on the radar right away...

Take a look at our bugs list to see if someone is already demanding for something you may be looking for as well.

Onto a "Feature Complete" AutoComplete extender!