Skip to main content
Home Forums Silverlight Programming Programming with .NET - General Silverlight Combobox that handles key press
6 replies. Latest Post by justintoth on June 21, 2009.
(0)
justintoth
Member
161 points
106 Posts
06-14-2009 12:36 PM |
Hey all,
Does anyone have a class that extends ComboBox that handles selection of items by pressing a key? And no, I don't want to use the AutoCompleteBox. I'm basically just looking for a ComboBox that works like the html one (which is how the built-in one should behave.) Let's say we have a state dropdown, when you press m it might select Maryland, then when you press m again it might select Massachusetts. I have one that works right now but it only works for the first time you press a letter, I couldn't figure out a way to select the next items with that letter.
Here's the code I have so far:
http://pastebin.com/m72da0672
I figure many people have already tackled this problem so didn't want to reinvent the wheel. I'm using SL3 beta if it makes a difference. Thanks for any help...
06-19-2009 10:06 PM |
:: bump ::
jackbond
Contributor
2820 points
725 Posts
06-20-2009 2:15 PM |
I raised this issue a while back in Silverlight 2, and was hoping it would be fixed in Silverlight 3, but the beta didn't get my hopes up. I know they are targetting LOB apps for Silverlight 3, and this deficiency makes the ComboBox almost unuseable. I really don't understand how it got this far like this; it's like the developers of the ComboBox have no idea how a ComboBox is supposed to work.
Krasshirsch
Participant
1042 points
300 Posts
06-20-2009 3:22 PM |
The silverlight combobox does not behave like a regular combobox, because it shouldnt.
Since in ASP, MFC, WinForms all Comboboxes can only contain strings you can actually perform string access operations inside them, theres no harm in doing so.
The Silverlight and WPF Combobox does not have this limitation and can consist of complex visual elements on the presentation side and complex classes on the data side.
Since there is no guarantee, that somewhere within this complex structure is actually a string that will be used as the SelectedValuePath, it would be mostly unwise to bloat the combobox with features that do only work in certain situations and environments.
So no, you have to implement those feature by urself.
private index = 0; private lastKey = Keys.Escape; // or something which i not used often private IList<string> list; OnComboboxKeyUp(DependencyObject sender, KeyEventArgs e) { if(e.Key != lastKey) { list = // get all entries starting with the letter represented by e.Key from the itemssource index = 0; } else { index++; // check if out of bounce, return to 0 if true } ComboBox.SelectedValue = list[index]; }
I just typed this down without testing but it should give you an idea
06-20-2009 5:09 PM |
I completely disagree... Even if it's bound to a collection of business objects, 9 times out of 10 the DisplayMemberPath is going to be a string. They could easily provide this functionality so long as that property is a string. Alternately, you could have a property for enabling it, which would throw an exception if DisplayMemberPath is not a string property of the business object.
You end up making every developer face the same issue, which either cuts down productivity, or if you choose to ignore it, cuts down the usability of your application. The fact of the matter is that end-users expect the dropdown to behave the same in Silverlight as it would in an html web application. It's one thing if the Silverlight combobox does more than the html one, but for it to do less is unacceptable.
Thanks for the code sample, I'll try it out later.
06-20-2009 9:04 PM |
Krasshirsch:The silverlight combobox does not behave like a regular combobox, because it shouldnt.
Gotta disagree 100%
Krasshirsch:The Silverlight and WPF Combobox does not have this limitation and can consist of complex visual elements on the presentation side and complex classes on the data side.
And yet the WPF combobox behaves properly, which almost completely invalidates your argument.
Krasshirsch:Since there is no guarantee, that somewhere within this complex structure is actually a string that will be used as the SelectedValuePath, it would be mostly unwise to bloat the combobox with features that do only work in certain situations and environments.
Like the original poster said, there's no reason not to detect that automatically at runtime (just as the WPF combobox does.) For my money, while the combobox CAN be used to display arbritary content, my guess is that most of the time (particularily in LOB apps) it will be displaying text. And even if that isn't true, the fact that EVERY combobox I've ever seen (including WPF) supports this functionality, makes a pretty strong argument that that's how the Silverlight one should behave. If it doesn't, it just confuses the user. I mean honestly, how many times have you seen a combobox populated with states, and been able to quickly select your own with just a few clicks.
Krasshirsch:I just typed this down without testing but it should give you an idea
I played around with the WPF combobox to get an idea of its behavoir. Under the hood, onkeydown is simply selecting the next item whose .ToString() method returns the first letter of the key that has been pressed. So if you add (via XAML):
<Border><TextBlock Text="I don't start with S" /></Border>
and then (via code)
"System.Windows.Controls.Ba"
"System.Windows.Controls.BZ"
Then pressing S will scroll through all 3 of the items (the first evaluating as "System.Windows.Controls.Border".) With that in mind, you simply have to jump to the next ToString that matches (cycling to the beginning if necessary, unless the shift key is being pressed, in which case, you cycle backwards.) Regardless of implementation, it really shouldn't be that much code, so I don't see how it could "bloat" the runtime. To go back to what I said before, not having this functionality simply confuses users. Even worse would be when some engineers (seeking consistency with standard implementations) add this on their own, while others do not. Then you've got a crap shoot, and that just can't be good.
06-21-2009 12:23 AM |
OK I'm obviously going to give the points to the guy who agrees with me, no hard feelings. :)