Thanks Milko,

The problem with using the same value type is then back end binding issues with the entity classes.  Will have to make temporary holding fields and such like.

The other issue is cross contamination, say for instance the behind the scenes "Long ID" is 158, but the product code for a product is also 158 but it's behind the scenes value is 190.  I guess a not in list check could probably cater for this but it makes things more complicated.

Is it possible not to have the editor cast to the value member type when something is entered that isn't in the list.  Simply return null? Maybe an option on the control to allow this.  I.E. Cast null to value member when item not in list.  That would solve the problem.

We typically inherit and build custom controls based on the Infragistics one.  Is there an override I can put on the control to do this?  I tried overriding the value {get;set;} but that doesn't seem to trigger.

Hi,

The problem is that your ID field is of type 'nullable long'.

If you choose an item from the list, then your combo is converted the text into a long. In that case, there's no problem.

If you type something that is not on the list, the combo returns the text you typed. Since that text cannot be converted into a long, there are exceptions being raised and caught by the editor. You don't see the exceptions, because they are caught, but they still slow down execution.

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.

Typically, in a case like this where the field in the grid cannot accept an invalid (string) value, you would set the column's Style to DropDownList. This would force the user to choose an item from the list and disallow typing. You could add a null option to your list, also, if you like.

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

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.

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.