I'm using an UltraCombo in the DropDown style and using AutoCompleteMode set to SuggestAppend. In my code I'm using the SelectionChangeCommitted event. Everything works like I expect, EXCEPT in the following scenarios...
Lets say I have a few Items such as Cabin1, Cabin2, Home1, Home2, Home3, Office1, and Office2 in the DropDown list.
If I select Home1, then using the Backspace key I remove the "1" leaving just "Home", the UltraCombo will nicely show me a small DropDown with the three Home(X) options. If I use my up or down arrow keys and highlight Home2 and then hit the Tab key, the UltraCombo will set the Text\Value to Home2 and my cursor will leave the UltraCombo box and the SelectionChangeCommitted NEVER fires.
Alternatively, instead of using the up and down arrow keys, once the DropDown with the three Home(X) options appears, I can Click on Home2 with my Mouse and, again, the UltraCombo will set the Text\Value to Home2, my cursor STAYS in the UltraCombo box and the SelectionChangeCommitted NEVER fires.
I believe both those cases (which I'm sure are due to the same root cause) are errors. The SelectionChangeCommitted event SHOULD fire because the user has in fact changed the selection.
This problem is in both version 2008 Vol3 and 2009 Vol1.
By the way, I NEVER get email notification of replies to my posts on this forum, even tho the "Email me replies to this post." is checked, the settings in my profile for allowing email notifications are checked, and my email address is in my profile... Somethin' not quite workin' right there...
The Infragistics.Win.UltraWinGrid.UltraCombo control does not expose a SelectionChangeCommitted event, so I am assuming here that you are actually referring to the Infragistics.Win.UltraWinEditors.UltraComboEditor control.
Wolven said:If I select Home1, then using the Backspace key I remove the "1" leaving just "Home", the UltraCombo will nicely show me a small DropDown with the three Home(X) options. If I use my up or down arrow keys and highlight Home2 and then hit the Tab key, the UltraCombo will set the Text\Value to Home2 and my cursor will leave the UltraCombo box and the SelectionChangeCommitted NEVER fires.
Wolven said:Alternatively, instead of using the up and down arrow keys, once the DropDown with the three Home(X) options appears, I can Click on Home2 with my Mouse and, again, the UltraCombo will set the Text\Value to Home2, my cursor STAYS in the UltraCombo box and the SelectionChangeCommitted NEVER fires.
Yes, I meant the UltraComboEditor...
I have a sarcastic wit and a biting sense of humor, so picture the comments below being said with a grin...
My mommy taught me at a young age that just because little Johnny next door craps on his porch isn't going to be accepted as a valid reason for emulating his behaviour... Likewise, just because the MS ComboBox doesn't work correctly (or logically) doesn't mean IG should emulate their stupidity. Is that some sort of Marketing\Selling point? "Hey, Our controls are just as F@#$^ up as Microsofts!" Wow... how cool is that? "Yeah, and when they fix theirs, then We'll fix ours!" Logic like that could almost make someone wonder why they aren't just using the "free" MS controls that came with their IDE...
The entire purpose of the SelectionChangeCommitted event is to notify the program(mer) that the user changed the text in the control. The fact that under certain circumstances it FAILS to fire when the user DID IN FACT change the text (selection) IS NOT A Feature! It's a bug. And whether the user clidked the mouse, the enter key, or the tab key doesn't matter. The question is, DID THEY CHANGE THE SELECTION? And in the scenarios I described, the answer is, YES, the user changed the selection. Just because the MS ComboBox has the same bug is irrelevant, and a worthless, unacceptable excuse.
As for the second scenario you quoted, I didn't describe it quite right. I backspace to change Home1 to Home, then when the dropdown with the three Home(X) options appears, I use the arrow key to go down and highlight Home2, THEN I grab the mouse and click on the already highlighted Home2. At that point, the dropdown closes up, the value in the combobox is Home2 (IT WAS CHANGED!) and the event doesn't fire.
All of the scenarios I described in my note on the case function EXACTLY the same with the sample application you built. I added MessageBox.Show(IG SelectionChanged) and MessageBox.Show(MS SelectionChanged) lines to your sample program. I'm sure they're redundant, but being somewhat new to VS, I didn't understand how to use your Debug line. Anyway, your sample app has the exact same behaviour (BUGS) as my app.
I notice the case status is "Closed". I think that's completely wrong. The problem still remains. And again, arguing that the MS combobox has the same problem is meaningless. Please, reopen the case and FIX the damn problems.
Thanx
Wolven said:Mike, I seriously doubt you would break any existing applications by making the event fire under the circumstances I've outlined. I'd be willing to bet that anyone using the SelectionChangeCommitted event simply hasn't noticed the rare occaisions I've pointed out where it doesn't work correctly. Over 95% of the time, the control is working just as we'd expect. I think if you (or anyone) sat down, played with the control while watching the SelectionChangeCommitted event firing, and then followed the steps I've given for duplicating the "bugs", you (or anyone else) would agree that the control simply isn't working correctly.
It's notoriously hard to judge something like this. You could be right and perhaps this would not break existing applications. But I know for certain that you are not the first person to report this issue and I have to think that some of the others are probably using workaround code to get around the issue. Changing the event firing would almost certainly break existing applications for those developers and it's really not something we can do at this point.
Wolven said:Obviously, the MS ComboBox has some bugs in it. As I asked before, WHY would IG knowingly duplicate a bug in a MS control??? That REALLY doesn't make any sense. Believe me, I fully support consistency... but NOT to the point of duplicating obvious errors. If I (or anyone else) wanted the control to work EXACTLY like the MS version, WHY wouldn't I just use the MS version in the first place?
As I said, I tend to agree that the behavior of the MS ComboBox does not make a lot of sense. But I'm not so sure that it's obviously a bug. Perhaps there is some other explanation that Microsoft could provide for why they implemented it this way.
Either way, the UltraComboEditor was original written using the MS ComboBox to provide it's dropdown list. So when the control was created, there was no choice for us but to follow the ComboBox behavior. We no longer use the ComboBox control, but the control has kept the same behavior to maintain backward compatibility.
The reason you would not use the MS ComboBox in the first place is that the UltraComboEditor has features that the MS ComboBox does not, such as appearances, display styles, and the ability to be embedded in a control like the UltraWinGrid.
By the way...
Mike said:But I know for certain that you are not the first person to report this issue and I have to think that some of the others are probably using workaround code to get around the issue.
The fact that multiple people are reporting the same bug SHOULD be an indication to IG that it IS in fact a bug and it SHOULD be fixed.
I'd MUCH rather go back and eliminate workaround code in my existing programs and have a control that works like it should, than HAVE TO ADD workaround code to all my new programs to deal with a problem the vendor won't fix...
Wolven said:I'd MUCH rather go back and eliminate workaround code in my existing programs and have a control that works like it should, than HAVE TO ADD workaround code to all my new programs to deal with a problem the vendor won't fix...
That's good if you happen to notice the change in behavior before you ship your product. But this would be an pretty subtle and easy-to-miss behavior change. And most of our customers would be pretty upset with us for breaking their applications. I'm afraid we cannot change this behavior at this point.
This is just nuts... Yeah it's broke, but no, we won't fix it.
How about a 3rd option... Fix the problem AND add a property to the control that determines whether it runs the New (fixed) event firing or the Old (broken) version... and have the property default to Old. That way you CAN fix the problem without "breaking" (fixing) other customers code.
As I already said... what we could do here is add a new event - one that does what you would expect the SelectionChangeCommitted event to do.
But this is not a bug, it's a feature request. Submit a feature request to Infragistics