Ahh thanks Mike, I was thinking about giving the UltraCombo a go to see if it exhibited the same behaviour but wanted to see if there was a way around it with the ComboEditor first due to the lighter weight of the control, and it's a really nice control we use a lot in a lot of areas.  But we can certainly use the UltraCombo in the grid sections in these situations.  I'll check out the sample.

Thanks for looking into it.

If possible, in the future, it would be nice if the UltraComboEditor didn't throw the exceptions in this situation. Is the change made to the UltraCombo possible to be made to the UltraComboEditor?  Anyway, we'll make do with the UltraCombo for now.

Hi,

Okay, that does make sense, then, if you intend to allow the user to type new items and then add them to the list.

I took another look, because I was curious as to why the UltraComboEditor was attempting to convert the text into a long on every keystroke. What's happening is that if you applied an appearance to the items on the list, when you select that item, the grid cell picks up that appearances. So the conversion occurs because the combo is trying to find a matching item on the list in order to update the appearance of the cell.

I can't find any way around this with UltraComboEditor, but the good news is that I was able to get this working using UltraCombo, instead. We added a property to UltraCombo a while back to prevent it from trying to convert the values into strings for the purposes of matching.I have attached a modified version of your sample here.

On another note Mike, the combo box when the value member is bound to a nullable long, to a standard POCO class through a binding source on a form and used in the same fashion it works fine.  It's only when it's used in a grid cell as an editor the lag occurs, even though it's bound to the same underlying POCO class.  

"Frankly, the way you have this set up doesn't really make sense. The user can type into the cell, but there's no way what they type can possibly be saved to the data source, so there's really no point in it. It can only cause confusion. "

Not really.  If the combo box worked properly and didn't get laggy when someone types something that isn't in the list, the system can then prompt the user if what they entered should be added to the list, or not.  If not, it stops them from saving the record until they select something valid, if yes, the item is added to the list dynamically and a new entry is made to the list and everything works fine.  It works this way fine, except for the lag.

It's quite easy to save and ensures the new entry is made to the lookup list dynamically. 

Drop down lists don't work because then the user can't enter something they want dynamically automatically added to the list.

I haven't come across this issue with other vendors combo controls.  This technique has been used right back to Microsoft Access days.  Someone enters into something into a combo box that doesn't exist in the list, the item can then be dynamically added to the lookup list or a different action taken. There are many reasons for using the long, for example the list could simply be products, or clients, and so on, in which case you don't want to bind the client name, or product description.  But you still want to be able to enable dynamic adding if the user enters in a new product description, or client name.