For the last few days I’ve been adding validators to my DAL for the project I’ve been working on. This project is again using the LLBL Gen Pro generated datalayer. Last time I had the validators working so they would catch my custom validation errors and throw them to the application as exceptions. Today I had to setup something to catch these errors and display them to the screen.

Of course, as always, things are never as simple as they first appear. One of the things that's changed in the most recent releases of LLBL Gen Pro is that they have implemented IDataErrorInfo on the entities, which is a standard interface provided in the System.ComponentModel namespace. This allows the developer to attach an error message directly to a field on an entity, so when we go displaying the errors we know who to highlight. Unfortunately there seem to be some issues with the way M$ defined this interface.

One of the odd things with this interface is that it implements a .Item property. Now that doesn't seem odd until you realize that the .Item property is extremely common in .NET classes, and it is usually the indexer to boot. By declaring the interface to have such a common name, M$ made it virtually impossible to ever access the list directly from the class the interface is defined on. Instead you have to cast your object to an IDataErrorInfo object so that you can get to the .Item property. This is a little odd, but workable once you figure it out. It did have me scratching my head for a few minutes trying to figure out how to access the errors though. I was expecting a DataError property or something like that, not a .Items property.

Ok, so we write our DisplayErrors routine so that the first thing it does is cast the object-with-errors to an IDataErrorInfo object. Now you might think that we can access the errors using something like this

Dim dei As ComponentModel.IDataErrorInfo = ObjectWithErrors
For Each err As String In dei.Item
   'Handle error
Next

Well, guess what. Yup, that'd be too easy. I'm not sure what exactly the IDataErrorInfo.Item is defined as, but it is not a standard collection or hashtable. It doesn't support an iterator, you can't even define one for it. It doesn't have a Count property available either, so you can't even tell if anything has errors on it before you start trying to display them. You have to know exactly what key was used to put the error into the collection or you won't be able to get it back out again. Luckily my custom validator routine put the errors into the collection, so I can figure out what all the possible fields are that might have caused an error. So, the code has to look like this instead

For Each f As ORMSupportClasses.IEntityField In ObjectWithErrors.Fields

   'Check this column for an error (either nothing or zero length string)
   If dei(f.Name) IsNot Nothing AndAlso dei(f.Name).Length > 0 Then

      'Add the error to the list
      ErrList.Add(dei(f.Name))

   End If
Next

Here I'm looping over all of the fields on the entity to see if any of them have errors. Any errors that I find I add to a simple arraylist. I'll convert this arraylist to an HTML bullet list for display later. If the arraylist comes out the other side of the loop with nothing in it, I assume that there were no errors and I hide the error listing control.

Oh, and I have to check for zero length strings since the first time I run this (before a postback) there are errors only on the fields that have errors and the rest are nothing. But after the postback the errors are all cleared out for me, but they (meaning the guys as LLBL) did that by setting each of the possible errors to a zero length string. So either condition can mean no error...

 

This is definately one of those days that seems like it was way harder then it had to be...