InfoPath Validation And The Errors Property

12 January 2011

When developing InfoPath forms, sometimes doing your validation using rules in the designer isn't quite powerful enough. Luckily for us, InfoPath allows you to hook into the Validation event for controls within your form; but here's something to watch out for.

When developing a form that attempts to access the Errors property of the current form from within a Validation event, although it will work fine with InfoPath Filler and local forms, you may get an error that looks similar to the following when you deploy it as a browser-based form to a SharePoint instance:

Exception thrown from business logic event listener: Microsoft.Office.InfoPath.Server.Util.InfoPathLocalizedException: Calling this property or method from a hosting page is not supported. at Microsoft.Office.InfoPath.Server.DocumentLifetime.Document.EnsureDocumentIsNotInMode(DocumentMode mode, Ids exceptionMessageId, Object[] resourceParameters) at Microsoft.Office.InfoPath.Server.DocumentLifetime.XmlFormHost.get_Errors() at Microsoft.Office.InfoPath.Server.SolutionLifetime.XmlFormProxy.get_Errors() at LiabilityForm.FormCode.Attachment_Validating(Object sender, XmlValidatingEventArgs e)

Doing a bit of reflection shows us exactly where the code dies:

public override FormErrorCollection Errors
{
    get
    {
        EnsureDocumentIsNotHostRestricted(this.Document);
        this.Document.EnsureDocumentIsNotInMode(DocumentMode.VersionUpgrade, InfoPathResourceManager.Ids.VersionUpgradeOMErrorProperty, new object[] { "Errors" }); //error thrown on this line
        OMSecurityContext.ExecuteOMCall(this.Document.Solution, SecurityLevel.Domain, delegate {
            if (this._errorBoardPublic == null)
            {
                this._errorBoardPublic = new ErrorBoardPublic(this.Document.ErrorBoard);
            }
        });
        return this._errorBoardPublic;
    }
}

The DocumentMode.VersionUpgrade is a little bit of a red herring in this instance - I initially thought that my code was failing due to some issues around my form deployment and potentially the form being locked in some sort of version/update limbo, but actually it turns out that you just shouldn't access the Errors property from within the Validation event (in the same way that any attempts to modify the form will also raise an exception.)

While normally you would be able to use e.ReportError() and continue as normal, it won't work for cases where you have "validation control pairs" where a change to one control should also trigger validation, and you need to raise errors targeted at a control of your choosing (not just the parent control of the Validation event).

Instead, you need to switch to the Changed event - this will allow you access to the Errors collection, but will unfortunately be slower as it requires a roundtrip to the SharePoint server, and there will also be some visible flashing/reloading of content. Don't forget that you'll also have to set all the controls you intend to validate in this fashion to always postback the data to the server, otherwise the validation won't get called at the correct time - you can do so from the Browser Forms tab in the target control's Properties:

Infopath Gotcha

I couldn't find a lot of information out there about DocumentMode.VersionUpgrade, or around this gotcha in general - even the MSDN article on XmlEvent.Validating shows an example using the Errors collection directly, but it definitely wasn't working for me within the browser on my checkboxes and attachment control. If anyone has encountered a similar issue, or has any more insight to the problem in general, please feel free to comment below.

Tags: errors, InfoPath, validation

Add a Comment

No Comments