VAB: GetExistingValidatedControlItem throws NullReferenceException

Topics: Validation Application Block
Mar 21, 2007 at 10:04 AM
Hello,

ValidationProvider.GetExistingValidatedControlItem throws NullReferenceException

I don't know if this is a bug or misconfiguration, that is why I decided to post it in here.

In this method, the collection "this.items.Values" has all controls that are on the form. Of course by far not all of these should get validated and only a few (5/12 in my case) have the property "PerformValidation on" set to true.

So when you iterate over that collection and check for validatedControlItem.SourcePropertyName, sometimes this value is null.

A simple check for null solved the problem:
if (validatedControlItem.SourcePropertyName == null)
    continue;

I could reproduce that problem also with the standard PropertyComparisonValidator.

The downside is I can't use the precompiled Microsoft libs anymore now.

It would be nice to hear if this is really a bug or if it's a fault on my side.

Thanks!
Andreas
Mar 21, 2007 at 3:40 PM
How are you getting the error?

The GetExistingValidatedControlItem method is internal to the assembly so how is it getting called to produce the error? I haven't looked through the source code in detail, but perhaps the items Hashtable used by the method has been filtered beforehand to only include controls where the error would not occur.

Regards,

Dave

_____________________

David Hayden
Microsoft MVP C#
Mar 21, 2007 at 4:05 PM
Edited Mar 21, 2007 at 4:16 PM
I can produce this error simply by using the PropertyComparison validator (which is probably the only validator that really uses that function, as it is used to get values of other properties than the property that gets currently validated). Anyhow here is the configuration:

<property name="Items">
 <validator operator="Equal" propertyToCompare="TotalItems" negated="false"
              type="Microsoft.Practices.EnterpriseLibrary.Validation.Validators.PropertyComparisonValidator,
                    Microsoft.Practices.EnterpriseLibrary.Validation, Version=2.9.9.2, Culture=neutral, 
                    PublicKeyToken=null"
              name="Property Comparison Validator" />

So as soon as you validate the windows forms textbox that is associated with the Items property the PropertyComparison validator gets executed.
In the DoValidate method this.valueAccess.GetValue(...) gets called which calls the GetExistingValidatedControlItem method.

The sourcePropertyName shows "TotalItems" at this point as this is the property we are interested in. The this.items.Values has 12 items (all controls on the form). The first in the hash table is my Exit Button which of course should not be validated and has no SourceProperty value. Then the NullreferenceException gets thrown if you execute the Equal check in the foreach loop.

I could send you the complete code if you are interested, but I can't see why you wouldn't get this error. Please note that this error only occurs on Windows.Form Validation (not on code based object validation) and you should have more than 2 controls on your form :), otherwise probably all controls have a SourceProperty value other than null.

Regards Andreas
Apr 11, 2007 at 10:09 PM
Has anyone managed to find the correct solution to this. I have posted an entry to Tom Hollander about it as I came across the same problem today.
Apr 12, 2007 at 12:17 AM
Quick question for you - do you have both of the properties (the one with the validator and the one being compared to) mapped to controls? This is necessary for the integration adapters to work.

Tom
Apr 12, 2007 at 9:00 AM
Edited Apr 13, 2007 at 8:17 AM
Tom,

All I added to the Validation Quickstart was the additional validator (see below) in the configuration file to the property 'FirstName'

            <validator operator="Equal" propertyToCompare="LastName" negated="true" 
messageTemplate="First Name cannot be Same as last Name" 
              type="Microsoft.Practices.EnterpriseLibrary.Validation.Validators.PropertyComparisonValidator
, Microsoft.Practices.EnterpriseLibrary.Validation, Version=3.0.0.0, Culture=neutral, PublicKeyToken=null"
              name="Property Comparison Validator" />

Both properties are mapped to controls on the mainform as per the Validation Quickstart.

Hope this helps
Apr 12, 2007 at 6:38 PM
Crap - I think you're right. I'm really sorry we didn't pick up on this before the release. It looks like the issue can be fixed by modifying ValidationProvider.GetExistingValidatedControlItem by changing
if (validatedControlItem.SourcePropertyName.Equals(sourcePropertyName))
to
if (validatedControlItem.SourcePropertyName == sourcePropertyName)
...since == is null-friendly but .Equals isn't. Again, apologies that this slipped through the cracks. We should start looking at a patch roll-up to deal with the few issues that have been discovered post release.

Tom
Apr 12, 2007 at 8:34 PM
We looked into this a bit more and found that the real cause of the problem is that the Winforms designer is generating code that sets the extender property values on all controls (even when validation isn't enabled), which is causing the controls to be incorrectly added to our collection. The problem is fixable by changing the code, but there is an (admitedly ugly) workaround that will make it work without changing the Entlib code, which is to set the SourceProperty for all controls to something other than an empty string, while only turning validation on for the controls that actually need it.

Tom
Apr 13, 2007 at 8:19 AM
Thanks for the update. I'll apply the fix and wait for a patched version of the Enterprise Library. Any update on the other bug regarding the messageTemplate disappearing when using the Configuration editor for a Property Comparison Validator. I posted the details in your blog.

Neal.
Jul 25, 2007 at 11:26 AM
Hi there,

yesterday I found this post and felt lucky to read about Enterprise Lib 3.1 fixing it. After installing the new version the problem is quite the same. I am sure I missed something. Is there anybody to help, any suggestions? Thanks a lot

Claudia
Jul 25, 2007 at 4:00 PM
Hi Claudia,

This was actually a design time issue: controls that didn't require validation were registered anyway with the validation provider. If you are using your windows forms as created with EntLib 3.0 with the new version the issue may still show up. Please make sure you regenerate your form with the new validation provider, so the code that gets generated is well formed, and also that all your validated controls do have a source property name set.

Hope this helps,
Fernando
Jul 26, 2007 at 7:45 AM
Hi Fernando,

thanks for this fast reply. Does this mean, I have to remove the validations first and add them again after building the form once without any validation? In my first attempt I just deleted the references To EntLib 3.0, inserted new references to EntLib 3.0 and rebuilt the whole thing. Or do I need start from the beginning with a blank form and adding all the controls? I am not a native speaker of English, so I am not sure about the exact meaning of "regenerating the form". Thanks a lot!

Claudia
Jul 26, 2007 at 1:27 PM
Hi Claudia,

The problem is that the bogus code generated at design time will not be replaced just by updating the references. This is why regenerating the code for your forms should take care of the issue; just update the form in some way, undo the the change and save.

Regards,
Fernando
Mar 28, 2008 at 6:01 PM
Got a problem with EntLib3.1 VAB PropertyComparisonValidator.

I have a page with 2 instances of a usercontrol .This user control has a textbox and a propertyproxyvalidator for validation. I have a class with properties startdate and enddate and the propertytovalidate for the propertyproxyvalidator in each instance of usercontrol is set in the page runtime.

I have defined a PropertyComparisonValidator on startdate property to validate it less than enddate.

My problem is when validation is fired,I get an error "Failure to retrieve comparand for key "enddate": The property name "enddate" is not mapped to validators in the naming context..

Thanks in advance..