I believe this can be considered a bug, or maybe it's "a feature" Anyway, the column name in the IDataErrorInfo support is case sensitive, this can be misleading.

If I set an error message using

MyEntity.SetEntityFieldError("IDNumber", "error:  this is an invalid number", False)

when I try to get the error message I have that

DirectCast(MyEntity, IDataErrorInfo).Item("IdNumber") return nothing
DirectCast(MyEntity, IDataErrorInfo).Item("IDNumber") return "error:  this is an invalid number"

Another issue is that you can have 2 or more error messages on the same column

MyEntity.SetEntityFieldError("IDNumber", "error:  this is an inavlid number", False) 
MyEntity.SetEntityFieldError("IdNumber", "error:  this is a negative number", False) 
MyEntity.SetEntityFieldError("idNumber", "error:  this is a absurd number", False) 

and this will result in

DirectCast(MyEntity, IDataErrorInfo).Item("idnumber") return nothing
DirectCast(MyEntity, IDataErrorInfo).Item("IDNumber") return "error:  this is an invalid number"
DirectCast(MyEntity, IDataErrorInfo).Item("IdNumber") return "error:  this is a negative number"
DirectCast(MyEntity, IDataErrorInfo).Item("idNumber") return "error:  this is a absurd number"

I believe it's possible to fix this feature/bug in 2 ways

1) instantiate the FastDictionary(Of String, String) that hold the IDataErrorInfo using a (System.StringComparer.CurrentCultureIgnoreCase) 2) use a "fildName.ToLower" inside the methods SetEntityFieldError / IDataErrorInfo.Item

Another side-effect I've just discovered is that you can set/get error messages for fields that don't exist,

MyEntity.SetEntityFieldError("AbsurdFieldNameThatDoesentExistInMyEntityBlaBlaBla", "error:  bla bla bla", False)

but probably this isn't much important...

I've discovered this bug/feature because I'm implementing the support for a "per field warning message" in our DAL. This work like the IDataErrorInfo, so I looked at how you have implemented the IDataErrorInfo support. Now in my IDataWarningInfo implementation I'm using the "fieldname.toLower" fix, because the FastDictionary doesn’t have a constructor that accepts a System.StringComparer.CurrentCultureIgnoreCase. The purpose of the IDataWarningInfo is to hold a per field warning message that will be shown to the user. The difference is that an error message comes from a blocking error, instead a warning message is just a "not-blocking" informative message, so that the user could still save the data even with some warning message. Naturally I've implemented the needed support in our GUI framework to detect and show the warning messages.

Max wrote:

I believe this can be considered a bug, or maybe it's "a feature" Anyway, the column name in the IDataErrorInfo support is case sensitive, this can be misleading.

Not a bug nor a feature. It's just the way it works

Max wrote:

If I set an error message using

MyEntity.SetEntityFieldError("IDNumber", "error:  this is an invalid number", False)

when I try to get the error message I have that

DirectCast(MyEntity, IDataErrorInfo).Item("IdNumber") return nothing
DirectCast(MyEntity, IDataErrorInfo).Item("IDNumber") return "error:  this is an invalid number"

Another issue is that you can have 2 or more error messages on the same column

MyEntity.SetEntityFieldError("IDNumber", "error:  this is an inavlid number", False) 
MyEntity.SetEntityFieldError("IdNumber", "error:  this is a negative number", False) 
MyEntity.SetEntityFieldError("idNumber", "error:  this is a absurd number", False) 

and this will result in

DirectCast(MyEntity, IDataErrorInfo).Item("idnumber") return nothing
DirectCast(MyEntity, IDataErrorInfo).Item("IDNumber") return "error:  this is an invalid number"
DirectCast(MyEntity, IDataErrorInfo).Item("IdNumber") return "error:  this is a negative number"
DirectCast(MyEntity, IDataErrorInfo).Item("idNumber") return "error:  this is a absurd number"

The general usage people use this is, indicate the fieldname this way:

involvedEntity.SetEntityFieldError(OrderFieldIndex.OrderDate.ToString(), ORDER_DATE_ERROR_MESSAGE, false);

And when reading the error, read in the same manner. That way you wont incur into problems displaying the error.

daelmo wrote:

Not a bug nor a feature. It's just the way it works

Absolutely! But IMHO I still "fill" that's a "way of working" that could give problem, doesn't give any advantage, and fixing it cost nothing

daelmo wrote:

The general usage people use this is, indicate the fieldname this way:

involvedEntity.SetEntityFieldError(OrderFieldIndex.OrderDate.ToString(), ORDER_DATE_ERROR_MESSAGE, false);

And when reading the error, read in the same manner. That way you wont incur into problems displaying the error.

Sure, this is true when you can hardcode the column name, but if you can't that's another story. In our GUI framework we have a Grid control, that incorporate an Infragistics Ultragrid. There is an event that is generated upon data error, in this event I get the IDataErronInfo from the underling Entity using the Key of the UltraGridColum. Naturally the key of the UltraGridColumn should match the case of the DB column... and it do, but there are a lot of code involved upon which I have no control (.Net binding framework, UltraGrid code... ), so there are a lot of place where the case could change.

Anyway, it's just me (I'm a VB developer) and I often look at "case sensitive" thing like something bad. But it's just me and my philosophy of software development

LLBLGen Pro is wonderful, and your support service is the best