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:The entire purpose of the SelectionChangeCommitted event is to notify the program(mer) that the user changed the text in the control.
Wolven said: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.
From reading the documentation (I don't remember if it was IG's or MS's) it sounded like the difference between SelectionChanged and SelectionChangeCommitted events was the fact that the SelectionChangeCommitted was fired ONLY by the user changing the value. i.e. programatic changes wouldn't fire the event. Which is what I'm after because my program does set the value under a number of circumstances and I don't want the processing I'm doing in the SelectionChangeCommitted event to be done under those circumstances i.e. when the program changed the value rather than the user.
I understand what you're saying about MSDN's documentation being a bit vague... But I would argue that "committed" means the value has been changed either to a Match or No Match condition And\OR that the value has been changed and the user has done something to indicate they're done changing the value (such as moving the cursor out of the control, hitting Enter, etc..)
Brian said:The tab key's purpose in this scenario is to navigate out of the control, and it doesn't have any specific significance with regard to selection.
While I agree that the purpose of the tab key is navigation, not selection, the fact still remains that the user Changed the Selection and the event Did Not Fire. What you're saying, in essence, would be like arguing that the Leave event not firing when the user pressed Shift Tab was O.K. because the purpose of the Shift Key isn't navigation... :)
I tend to agree with you.
I always though that the purpose beging the SelectionChangedCommitted event was to make it easier for the developer to determine when the user was done entering a value in a combo. Event's like SelectionChanged aren't really good for this, because it does not account for when the user types into the control. And TextChanged doesn't indicate whether the user selected from the list or typed - which is useful to know for validation.
Clearly, however, there are some holes in Microsoft's implementation of this, as you point out here. I guess MS had something different in mind when they added this event.
Unfortunately, the SelectionChangeCommitted on the UltraComboEditor mirrors the behavior of the Microsoft ComboBox. That's the way it was designed, with the assumption that the MS control is doing things the right way.
And while I agree that the way MS implemented this is not really very useful - at least not by the criteria I mentioned above, there's no way we can change the firing of the event without breaking existing applications. So the best we could do here would be to add a new event that does what you would reasonably expect the SelectionChangeCommitted event to do.
I recommend that you Submit a feature request to Infragistics and include a link to this thread and perhaps this can be imlemented in a future release.
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.
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?
Again, I SERIOUSLY doubt fixing this would break anything or upset anybody. Just like me, the few people that have even noticed the problem will have had to come up with a work around that would work correctly even if the event DID fire (like it should) in those scenarios I've given you. I really don't understand the reluctance to fix this problem...
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.
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
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.
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.
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...
I agree on not changing the Event Firing Order, if that's what you meant, but I totally disagree on not getting the control to fire the event WHEN IT SHOULD.
So, if IG doesn't fix this because of the "backward compatibilty" issue, WHEN do you ever fix anything? Obviously if someone has written code to workaround an IG bug (and I've written plenty), fixing the bug is going to eliminate the need for the workaround and MIGHT even mess up the program. If it messes up the program, then the programmer will have to fix it. After all, that IS what we do.
So do we just have to live with buggy controls forever just so we can maintain "backward compatibilty"? That just doesn't make sense.