Is it worthwhile to keep AutoCompleteBox’s DropDownOpening and Closing events?
Recently we’ve been going through another round of bug fixes and improvements to controls in the Silverlight Toolkit and SDK, and I’m looking to trim AutoCompleteBox where it differs a lot from the platform.
I’ve been gathering some feedback, and in an effort to be transparent about the process, I’d like to take this opportunity to ask the tubes. I’ve definitely met some customers at MIX and other events that are using controls like AutoCompleteBox for scenarios I’ve never dreamed of.
Would you miss these two events? If so, what scenarios or kinds of experiences are you building using the events today?
There’s a cancelable pattern implemented in the control for the drop down experience: DropDownOpening offers an event argument that can cancel the drop down open; if it isn’t canceled, DropDownOpened fires (like a standard ComboBox).
The same holds true for DropDownClosing offering a cancelation, followed by DropDownClosed.
Although it felt nice to add these as extensibility points, standard WPF and Silverlight controls like ComboBox just don’t offer these additional events, and I can’t come up with any great scenarios for keeping them around.
If I had to spend 2 developer days fixing bugs and issues with the cancelation, or 2 days adding better features and fixing the real issues affecting everyone, I’d drop the cancelable events right away.
BTW, DropDownOpened and DropDownClosed are definitely staying – it’s the Opening and Closing that are on the table.
Anyway, I’d love any scenario feedback. If there’s some important scenario that this enables, then not only do I want to hear about it, but I’d like to work to get test coverage added for your scenarios, so that we keep these events fine-tuned and operating in a good way.
Thanks for any input!
1. how do you know how frequently we use these events?
2. why make it ‘less rich’ ? I’m not sure I agree about remove events that developers are possibly using, regardless of frequency
@Steve,
From talking to customers who are using the control, on forums/blogs/conferences.
For making it “less rich,” part of the reason is that the cancel mechanism is a “bug farm” of sorts: it’s possible to have a popup that closes (and can’t be brought back), but yet the opening event can be canceled, at which point the state is still open, but visually it is no longer open, etc. This simplifies the model to one that is used in more places.
And the better question is, are you using the events?
I find these kind of events helpful when you want to change the state of the UI while the AutoCompleteBox is firing these events. For example, you may want to disable animation while the dropdown is opening (for performance reasons). I wish more of the controls had helpful events like these.
This events are useful.
I’m using the DropDownClosing event in a custom implementation of the AutoCompleteBox that I have done.