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