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.

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 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.

But this is not a bug, it's a feature request. Submit a feature request to Infragistics