I have a ComboEditor containing several values. The validation (IsItemInList()) works fine if I select the value from the pulldown, but if I type the value into the combo, then the IsItemInList() call always returns false. It is typed exactly as it is in the combo. Any ideas?
In what event are you performing this validation, and what's the code you're using in your IsItemInList() call?
I am firing this method in the validate event. It looks like this was working before we moved to 8.1.. any ideas?
We'll need more information to know what approach you're taking, and thus to determine whether the approach should work now or should have worked in the first place.
I suggest that you submit a support request so that a Developer Support Engineer can work with you to research this further. You should attach to this request a sample project that works if you run against our 8.1 assemblies but doesn't do what you expect it to do in later releases. We'll use this sample to research what's happening, determine if the result should be expected, and take steps to resolve the issue if a fix is required on our end.
Unfortunately, our dev environments are not on a network that I can copy code from. Unfortunately, you'll have to take my word for the fact that the isItemInList call worked for our combo boxes before, and now does not. We are simply adding strings to the control, nothing fancy, but unless we use the drop down to select an item, the IsItemInList always returns false. even when I step in the debugger and copy the exact string, nets the same result
It's not a matter of "believing" that the issue is happening when it didn't previously happen - I'm pretty certain you wouldn't spend time saying there's a problem if there wasn't!
A sample is important because it gives us the ability to test the same code you're using. When I say a "sample," I mean an application that is as concise as possible while still demonstrating the same behavior that you're experiencing in your application. At this point, we need such a sample to be able to continue research.
Well then, I guess you cannot help me, as I said earlier, getting code from our other system to this one is not possible, and we do not have dev tools or licences on our outside networks, so I don't know what to do at this point short of no longer using Infragistics
Some further information, it appears that we are overloading a few of the methods associated with the ultracomboeditor, one being the validated method, the other being ItemNotInList. I am seeing the ItemNotInList being fired every time I enter text into the field, I don't know if that is what is causing the trouble with the Validated field, however I did notice today, while I was stopped in the debugger, for the first, I'd say 30 seconds or so, the IsItemInList Method was working exactly how I described a few posts above, however, after about 30 seconds or so, it started to work correctly. So I am not exactly sure what could be causing this delay, but I thought it was notable.
Oh I do fully understand the difficulty for you if you can't reproduce, as you probably can understand my frustration if I cannot get sample code to you. I don't even have a computer easily available for me to contact your support, I can get to one of these kiosks maybe once or twice a day, which does not help me either... I'll do my best to help reproduce this issue. I will have to check to see if a case sensitive issue is at hand. I know that these events are handled in an overridden Validate handler, I believe the Combobox contains one of those. It looks like our code has overridden this to allow two of these conbos to utilize the same method. I belive the function is also fired when an OK button is pressed. I didn't see anything special in how the strings were added to the controls, but I will do some further investigation. thanks for your help
Greg
I tried to reproduce the problem you describe here with the latest version of the 2008.1 source, and was not able to. The IsItemInList method has two overloads; the parameterless one is implied to use the current value of the control's Text property, and the other one lets you specify the text. I tried both overloads, and both worked as expected, although I was somewhat surprised to see find that the method does appear to be case-sensitive. An overload could be added to allow the caller to specify whether to consider case when evaluating; if you like you can submit a feature request along those lines.
We certainly don't ever want to lose a customer, or miss the opportunity to fix an existing bug before it gets into the next release, but unless we can reproduce the issue, it makes it extremely difficult to fix it. As a developer you can surely understand this, so if there are any details you can provide that might help us reproduce, please repost and we can take a closer look.