Doing Data Validations in Infopath 2007 Programmatically

Infopath 2007 provides rich validation function for each of its controls. For ex, you can validate a text box or a field

For conditions such as equal to, is blank, is greater than and if that field fails the validation, we can display a message box.

One important thing to be noted is that, Infopath 2007 would not submit the form unless all the controls pass the validation.

Now, let’s talk about the complex validation, let’s say, I want to validate whether or not the textbox contains email address or not.

Surprisingly, this can be also done out of the box using pattern matching. If we look at the validation options in Infopath, one finds the options matches pattern, does not matches pattern. Here one can specify a complex regular expression to be matched.

Custom Validation

Now we come to our main topic, custom validation, means validation using some business logic which Infopath cannot provide out of the box.

To implement custom validation, each control in Infopath provides a validating event, which is usually called when the value of the control Changes. This is almost same as Changed event, with one difference that during the execution of validating event, the whole document tree is read only. That is, we cannot write to any field in Infopath while validating event is being executed.

The reason for this is that, the values of Infopath fields can change due to the change in values of other fields, which will result in Validating event to be called again and again, until the stack runs out of memory.

Now, coming to our main point, validating event, here we will see how to validate a simple field in Infopath, programmatically.

To write managed code in Infopath, you must have either VSTO or VSTA installed.

To write a validating event for a field, right click the field and choose Programming ->validating event

The code editor will open up the desired function for inserting the code for the validating event for particular field.

Below is an example of one of the typical implementation of validating event

public void OtherAttendees_Validate(object sender, XmlEventArgs e)

{

try

{

this.Errors.Delete("Invalid Value");

}

catch (Exception) { }

string str = e.Site.Value;

bool flag = CheckAttendees(str);

if (flag == false)

{

this.Errors.Add(e.Site, "Invalid Value", "The value of the "+ e.Site.LocalName + " field must be email addresses seperated by ;");

}

}

To understand the above code, we must first realize that this function will be called as soon as the value of the field will be changed.

We clean up the Errors collection prior to validating our field using this.Errors.Delete();

CheckAttendees function implements the business logic which determines that weather the field is valid or not. The input to the function is nothing but the value of the field.

Now, if the decide that field validation has failed, we add an error into the Error Collection using this.Errors.Add(), indicating the value and the custom error message we want to be displayed.

You can find out about the Errors collection here:

http://msdn2.microsoft.com/en-us/library/bb229714.aspx

Now the point is, if the Errors Collection contains an item, the Infopath will not allow to submit the form. And, if you try to submit it, it will highlight the particular field and display the custom error message.

Tip about Validation and Submit in Browser Forms

This sort of validation works fine in client form since everything is executed on client. However in browser based forms, the user would not come to know about the failure in validation until he clicks submit and this would cost an expensive server page postback.

To overcome this limitation, we can implement the same logic in Changed event handler and set a value of hidden field which would indicate the validity of the form at the time of submission. Now on submit button, we can use custom rules to check the value of the hidden field and prevent the submission at the client side only. This prevents considerable overhead of page postback.