>I have been developing a complex solution using InfoPath to gather user information before it is processed by a SharePoint / Windows Workflow foundation solution.
One of things that the client wanted to was make use of file attachment controls. One of the requirements that the forms were only available on infopath form services. However this causes problems as we cannot validate the file attachment control.
In order to get round this we can programme a event called OnValidate_ControlName which is fired when a field has changed.
The handler provides an argument, ‘e’ which allows you to interact with InfoPath.
The keys properties of e are the following:-
- Operation = this is the XmlOperation type that is occuring. This can be none, insert, delete and value change.
- Site = this represents the XPathNavigator for the control that is being checked.
- NewValue / OldValue = available for the value change operation type. This gives the developer a means to check the new and old values.
When I write an event validation function, I split the checks by Operation type. Therefore validation can be done based on the type of event.
The operation types are one of the following:-
- None – fired when the form opens.
- Value Change – fires when a value of a field is changed.
- Insert – fires when an insertion occurs with a repeating table.
- Delete – fires when a deletion occurs within a repeating table.
Using this method you can reduce the complexity of the checks for example you may only check that a field requires a value when a field is changed or a repeating table is inserted (to prompt the user to fill out the field.) The none operation can be used to pre-empt the user to fill out a value for a field as soon as the form is opened.
Once a problem is found, the user can be informed by the e.ReportError() function, which asks you to provide an XPathNavigator object pointing to the node with the problem. This is normally the e.Site object. There are a couple of other parameters, called Site Independent and message. The message parameter allows you to provide a simple message. An other override of the message allows more detail to be inserted. This is displayed in a separate message box.
The site independent is used in regards to when the fault clears and whether a change has to be validated against the same control or through a group control (such as a repeating table repeating field.
Tying things up
Programming this way provides some validation that is not possible in the out of the box solutions and provides a way to provide much better methods to interact with the user.