Feature complete AutoComplete extender? Not yet.

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!

Comments

• Anonymous
  January 01, 2003
  Hi.  I had a need for an additional filter parameter for an AutoComplete to be able to use two of them as a Cascading DropDowns.  I added that and have been using it in my dev environment for a couple weeks - works great! I also needed it to attempt a call on an empty textbox.. (ie.  Once the filter has been set, call the Select to populate the filtered values) however it was continuously calling the service. I implemented a RetryCallLimit which allows the user to set a limit on repeated calls to the service.  If the filter or value in the textbox is changed, the RetryCallCount is reset. Anyway, I'm glad to hear there are more updates on the way and would love to help you out if I can.  If you're interested in the above functionality, just let me know and I'll shoot you out my code. Wayne Wayne@OurCurrentFuture.com

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  Good idea, I'll try it

• Anonymous
  January 01, 2003
  Is the autocomplete ready to work with screen readers? I couldn't get it to work with JAWS. The trick is to be able to have JAWS read the list item AND be able to choose it. If this is possible, please post the answer. Thank you.

• Anonymous
  January 01, 2003
  Wayne, we are glad to hear that you would be interested in contributing some fixes. You can always attach the code changes to existing issues in the issue tracker and we can pick them up. We are currently working on making that process more streamlined so that Toolkit users can provide fixes and allow us to incorporate those easily. Expect some news in that space soon.

• Anonymous
  January 01, 2003
  Aidan, have you considered using DynamicPopulate with PopupBehavior in Toolkit?