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.

No, using tables is not really appropriate.  We Code First Entity Framework 6 and directly bind to the POCO classes utilising a customised BindingList to provide the child records which then handles the additions / removals from the parent etc.  Using the POCO classes allows us to build in logic, and implement IDataErrorInfo which works well with the grid.  The grid works fantastically well in this scenario, except for the combo box lag.  Binding the grid directly to the Binding list has the same issue.

Sample Binding List we use (T is the child entity, while P is the parent entity).  The child entity implements IDataErrorInfo which is wingrid understands.  Translating this to a datatable doesn't work well as then we lose the POCO capabilities on the fields, real time calculation fields and so on which we like to keep in the POCO class for calculating the row totals, tax, and so on.

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data.Entity.Infrastructure;

using System.Linq;

using System.Text;

using System.Threading.Tasks;

using oneFlowProLib.Interfaces;

using System.Data.Entity;

namespace oneFlowProLib.Data

{

public class DetailItemBindableList<T, P> : BindingList<T>

where T : IDetailItem

where P : IBindableDetails<T>

{

private P myParent;

internal DetailItemBindableList(P parent)

{

myParent = parent;

foreach (var myItem in myParent.Details)

this.Items.Add(myItem);

}

protected override void RemoveItem(int index)

{

var myItem = this[index];

if (myItem != null)

{

myParent.Details.Remove(myItem);

if(myItem.ID>0)

{

var myContext = myParent.GetContext();

myContext.Set(typeof(T)).Remove(myItem);

}

base.RemoveItem(index);

}

}

public override void CancelNew(int itemIndex)

{

var myItem = this[itemIndex];

if (myItem != null)

{

base.CancelNew(itemIndex);

}

}

protected override void OnListChanged(ListChangedEventArgs e)

{

if (myParent == null)

return;

int indexPosition = e.NewIndex;

if (this.Count > e.NewIndex)

{

var myItem = this[indexPosition];

switch (e.ListChangedType)

{

case ListChangedType.ItemAdded:

myParent.Details.Add(myItem);

break;

}

}

base.OnListChanged(e);

}

public bool HasErrors()

{

return this.Any(a => a.HasErrors());

}

}

}

Sample Child entity which is what the grid binds to through the bindinglist

[Table("BankingDetail")]

public class BankingDetail : DataErrorInfo, IDetailItem

{

public BankingDetail() { }

#region Properties

[Key]

public long ID { get; set; }

[Required]

public long? CategoryID { get; set; }

public long BankingID { get; set; }

[StringLength(255)]

[Required]

public string Description { get; set; }

public decimal Amount { get; set; }

public decimal TaxRate { get; set; }

public decimal Tax { get { return (Amount * TaxRate).ToRoundedCurrency(4); } private set { } }

public decimal Total { get { return (Amount + Tax).ToRoundedCurrency(); } private set { } }

public decimal RunTotal

{

get

{

if (Banking.Type == Banking.BankingTypes.Deposit)

return Total;

else

return Total * -1;

}

private set { }

}

[StringLength(100)]

public string TaxCode { get; set; }

public virtual Category Category { get; set; }

public virtual Banking Banking { get; set; }

#endregion

#region Dynamic Properties

#endregion

#region Methods

public bool Validate()

{

this.ClearErrors();

if(this.CategoryID==null)

{

this.SetColumnError("Category", "invalid");

this.Error = "Category Required";

}

if(string.IsNullOrWhiteSpace(this.Description))

{

this.SetColumnError("Description", "required");

this.Error = "Description Required";

}

return !this.HasErrors();

}

#endregion

}

Ideally if there is an override on the ultracomboeditor we can override would be best, to avert the attempted translation, or whatever it is trying to do when the item isn't in the list.  Our combo control inherits the ultracomboeditor so we would have no problem overriding something it is doing if that is possible, and prevent the process from happening which causes the lag.

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.