I'm working hard to make sure that the AutoCompleteBox control is refined, perfected, and ready to become an important part of Silverlight. Now that the control shipped in the Silverlight 3 Beta SDK, we do have a little opportunity to make the right API changes before release, if they make sense. However, once the control ships in the "Mature" quality band, we've got to uphold the Silverlight Toolkit quality bands that we've set out: and that means no breaking changes.

Looking for your API experience and name feedback

Do you have any strong feedback? How's this all fit in with the Framework Design Guidelines? Naming? You'll find the official documentation for the Silverlight AutoCompleteBox control at http://msdn.microsoft.com/en-us/library/system.windows.controls.autocompletebox(VS.96).aspx (documentation subject to change).

Recent API changes

ValueMemberBinding instead of explicit trio of Converter properties

With the March 2009 release of the Silverlight Toolkit, we dropped the multiple Converter properties for the control, and went for the more powerful Binding experience by exposing the ValueMemberBinding property for handling object-to-text conversions.

Search becomes Filter

The AutoCompleteBox shipped in the first two Silverlight Toolkit releases with some mixed nomenclature, intermixing the use of "Filter" and "Search" to mean the same thing. Thanks to Cheryl's feedback (she's on the UE team), for the next release, these properties will be more consistent, using "Filter": so, imagine that the AutoCompleteSearchMode enum will become AutoCompleteFilterMode. Name changes, vs. functionality changes, should have minimal impact on existing applications, styles, and declarative XAML. But we only get one more chance really to make these changes.

Providing feedback

In general, you should provide feedback through the

• Silverlight.net forums
• CodePlex issue tracker for the Silverlight Toolkit

However, for this particular topic - API names - I think this blog post and the comment section will allow a quick conversation to happen, if you'd like to participate. And no big promises here: I'm only one person, and we'll still need to talk with our user education experts, program managers, test team, and make a call w.r.t. where to invest resources before shipping.

Mature Quality Band

The Silverlight Toolkit defines the Mature quality band as follows:

Mature components are ready for full release, meeting the highest levels of quality and stability. Future releases of mature components will maintain a high quality bar with no breaking changes except when such changes are necessary to make them more secure or guarantee future compatibility. Customers should be confident using mature components, knowing that when they upgrade from one version of the Silverlight Toolkit to a newer version it will be a quick and easy process. Due to the heavy focus on backward compatibility between versions, the bar for fixing bugs found in mature components is also considerably higher than any other Quality Band.

I'd really, really like your feedback and suggestions here. Thanks!